

Lessons from torvalds/GitHub commits discussion - normalocity
http://technicallyborked.com/2012/5/12/lessons-from-torvaldsgithub-commits-discussion.html

======
moonlighter
To save folks some time, here's the summarized version of what commit-
formatting Linus actually wants (for the kernel anyway):

[https://github.com/torvalds/linux/pull/17#issuecomment-56637...](https://github.com/torvalds/linux/pull/17#issuecomment-5663733)
[https://github.com/torvalds/linux/pull/17#issuecomment-56637...](https://github.com/torvalds/linux/pull/17#issuecomment-5663780)

------
kstenerud
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?

~~~
normalocity
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 believes this results in lost efficiency,
which gets worse the more commit messages you have to read/handle on
larger/more active projects.

If you work within GitHub's UI only (and rarely look at your shortlog / git
log on the command line), you'll never know about this because the web UI
hides this fact. That seems to be what Linus is getting at - that the tool
(git itself) was built to be awesome on *nix platforms, and GitHub effectively
ignores this aspect of git.

Finally, since the web UI doesn't enforce the proposed standard, you
effectively create two groups of people: people who work through the web UI
(or other UI-based tools), and people who work from the command line. Only the
command-line people really suffer. However, if everyone (even people who work
in the web UI) would conform to the standard, not only is everyone happy, but
it encourages people who write commit messages to be more succinct, effective,
and precise in their messages.

That's pretty much what I took from it.

~~~
kstenerud
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".

~~~
mjschultz
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] <first
line of commit>. 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 <patches>
    

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.

~~~
ajross
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.

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

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

------
zbowling
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.

------
diminish
Nice summary, though the tone of the discussion is a bit tense.

~~~
gft
Much of the other HN message board centers on the tone of the conversation. I
think an important message that shouldn't be lost is:

Emulate Linus' style in commit messages if you wish.

Don't emulate the abrasiveness in his style of communicating (unless you have
a track record as good as his).

------
ktizo
Crocker's rules might be useful in this case...

<http://www.sl4.org/crocker.html>

------
hcarvalhoalves
The _real_ lesson is: there are more important things to care about in life.

