Lessons from torvalds/GitHub commits discussion • Hacker News Board

Re: Lessons from torvalds/GitHub commits discussion

#11

Post by normalocity » Sat, May 12, 2012, 10:29 PM UTC

kstenerud wrote: post #8

normalocity wrote: post #6

Earlier quoted context omitted.

The deficiency basically has to do with git being primarily a command-line tool, and as such, it's most powerful/native tools are built to be perfect for viewing plain text/in the command line (which are also mono-spaced). As such, when you view commit messages that are too long in the command line, the formatting gets screwed up as text is wrapped, and it's more difficult to read. In my interpretation, Linus believe…

Right, that makes perfect sense. However, I still fail to understand Linus' outright refusal to even accept submissions made via a web interface rather than simply say "when you do a pull request, it must follow this format".

Hm, hard to say. I don't know Linus personally. If I had to guess, I'd say he was one fire about it, and is obviously passionate about it. People are people, and they get exciting about stuff they care about.

Re: Lessons from torvalds/GitHub commits discussion

#12

Post by normalocity » Sat, May 12, 2012, 10:34 PM UTC

jph wrote: post #9

It's more than formatting-- it's also identity verification, for example using email addresses and/or digital signatures.

You're right, I left that portion about, but it's also important.

Re: Lessons from torvalds/GitHub commits discussion

#13

Post by zbowling » Sat, May 12, 2012, 11:30 PM UTC

It really sucks because this was not even a 1/3 of the points made in the discussion but the comments were getting deleted on an epic scale.

Re: Lessons from torvalds/GitHub commits discussion

#14

Post by jasonwatkinspdx » Sun, May 13, 2012, 1:07 AM UTC

normalocity wrote: post #6

kstenerud wrote: post #5

I still don't understand what the problem is. Is it that github doesn't enforce a commit message standard? Or is it that github doesn't allow you to follow a commit message standard such as what Linus uses? Does git itself enforce a standard, for that matter? What exactly is the deficiency in github?

The deficiency basically has to do with git being primarily a command-line tool, and as such, it's most powerful/native tools are built to be perfect for viewing plain text/in the command line (which are also mono-spaced). As such, when you view commit messages that are too long in the command line, the formatting gets screwed up as text is wrapped, and it's more difficult to read. In my interpretation, Linus believe…

There is no reason the command line tools can't format long lines intelligently. But of course, that'd require admitting that the vast majority of git users are not in fact using git on an 80 column terminal from 1970 even if they are using it from console.

The rest of the points about identities, etc, are entirely valid, but I don't really see anyone objecting to Linus's view on those.

Re: Lessons from torvalds/GitHub commits discussion

#15

Post by MBlume » Sun, May 13, 2012, 1:44 AM UTC

jasonwatkinspdx wrote: post #14

normalocity wrote: post #6

Earlier quoted context omitted.

The deficiency basically has to do with git being primarily a command-line tool, and as such, it's most powerful/native tools are built to be perfect for viewing plain text/in the command line (which are also mono-spaced). As such, when you view commit messages that are too long in the command line, the formatting gets screwed up as text is wrapped, and it's more difficult to read. In my interpretation, Linus believe…

There is no reason the command line tools can't format long lines intelligently. But of course, that'd require admitting that the vast majority of git users are not in fact using git on an 80 column terminal from 1970 even if they are using it from console. The rest of the points about identities, etc, are entirely valid, but I don't really see anyone objecting to Linus's view on those.

Just because I can fit a wider-than-80-column terminal on my screen doesn't mean I want to. Maybe I want a bunch of terminals on my screen. We already have a software ecosystem that attempts to respect the 80-character limit -- why break that?

Re: Lessons from torvalds/GitHub commits discussion

#16

Post by mjschultz » Sun, May 13, 2012, 2:11 AM UTC

kstenerud wrote: post #8

normalocity wrote: post #6

Earlier quoted context omitted.

The deficiency basically has to do with git being primarily a command-line tool, and as such, it's most powerful/native tools are built to be perfect for viewing plain text/in the command line (which are also mono-spaced). As such, when you view commit messages that are too long in the command line, the formatting gets screwed up as text is wrapped, and it's more difficult to read. In my interpretation, Linus believe…

Right, that makes perfect sense. However, I still fail to understand Linus' outright refusal to even accept submissions made via a web interface rather than simply say "when you do a pull request, it must follow this format".

I think his refusal to accept from the web interface has more to do with the web interface being so far out of his normal workflow that it would be too disruptive for him. If you accept this pull request it might set some sort of precedent then you'd have to shoot down the next one--might as well just stop it in its tracks.

I didn't realize all the tools git has built-in (therefore developed with Linus's workflow in mind) for handling patches until I was poking around today:

    git format-patch origin

This creates a git-style patch for every unpushed commit I have. git-style meaning it's actually an email with the log, diffstat, and patch in it. If there are multiple commits the subject of the email will be [PATCH 1/n] . When you're dealing with many patches a day this gets the point across fast.

Better yet:

    git send-email origin

Same thing as above, but it hooks into your system's sendmail and sends the patch email(s) for you.

On the receiving end, you've got:

    git apply --check

You can make sure they'll actually work against your copy before diving in.

And most important to Linus is probably:

    git am --signoff

Which can hook into your mailbox and apply all the patches with commit messages and add the Signed-off-by line with your email account.

So if your workflow consists of looking at a patch in the terminal, then applying and committing that patch many times a day these things are very important to you and they provide you with the information you need very quickly.

Compare that to the point-and-click web interface of github, sure it works at low volumes but when you scale it up it becomes clumsy and slow.

I suspect his complaints about commit formatting and quality of github contributors doesn't help are more of the two more annoyances variety.

Re: Lessons from torvalds/GitHub commits discussion

#17

Post by technomancy » Sun, May 13, 2012, 2:20 AM UTC

kstenerud wrote: post #8

normalocity wrote: post #6

Earlier quoted context omitted.

The deficiency basically has to do with git being primarily a command-line tool, and as such, it's most powerful/native tools are built to be perfect for viewing plain text/in the command line (which are also mono-spaced). As such, when you view commit messages that are too long in the command line, the formatting gets screwed up as text is wrapped, and it's more difficult to read. In my interpretation, Linus believe…

Right, that makes perfect sense. However, I still fail to understand Linus' outright refusal to even accept submissions made via a web interface rather than simply say "when you do a pull request, it must follow this format".

The one good point he had was that you can't reliably track authorship since pull requests can't be signed.

The rest of it was Linus being a prima donna (rather than just specifying formatting guidelines that would be easy to observe with pull requests) because he knows he can get away with it.

Re: Lessons from torvalds/GitHub commits discussion

#18

Post by dredmorbius » Sun, May 13, 2012, 2:38 AM UTC

jasonwatkinspdx wrote: post #14

normalocity wrote: post #6

Earlier quoted context omitted.

The deficiency basically has to do with git being primarily a command-line tool, and as such, it's most powerful/native tools are built to be perfect for viewing plain text/in the command line (which are also mono-spaced). As such, when you view commit messages that are too long in the command line, the formatting gets screwed up as text is wrapped, and it's more difficult to read. In my interpretation, Linus believe…

There is no reason the command line tools can't format long lines intelligently. But of course, that'd require admitting that the vast majority of git users are not in fact using git on an 80 column terminal from 1970 even if they are using it from console. The rest of the points about identities, etc, are entirely valid, but I don't really see anyone objecting to Linus's view on those.

Linus actually addresses that specific point, several times, in the original discussion thread.

Please refer to his comments.

Re: Lessons from torvalds/GitHub commits discussion

#19

Post by hcarvalhoalves » Sun, May 13, 2012, 2:44 AM UTC

The real lesson is: there are more important things to care about in life.

Re: Lessons from torvalds/GitHub commits discussion

#20

Post by ajross » Sun, May 13, 2012, 3:26 AM UTC

mjschultz wrote: post #16

kstenerud wrote: post #8

Earlier quoted context omitted.

Right, that makes perfect sense. However, I still fail to understand Linus' outright refusal to even accept submissions made via a web interface rather than simply say "when you do a pull request, it must follow this format".

I think his refusal to accept from the web interface has more to do with the web interface being so far out of his normal workflow that it would be too disruptive for him. If you accept this pull request it might set some sort of precedent then you'd have to shoot down the next one--might as well just stop it in its tracks. I didn't realize all the tools git has built-in (therefore developed with Linus's workflow in…

It's also important to point out that this pull request never should have gone to Linus in the first place. It was a 2-line addition of a USB device ID. That should go to a subsystem (bluetooth in this case) maintainer.