Quoting from linux/Documentation/SubmittingPatches.txt
16) Sending "git pull" requests (from Linus emails)
Please write the git repo address and branch name alone on the same line
so that I can't even by mistake pull from the wrong branch, and so that
a triple-click just selects the whole thing.
So the proper format is something along the lines of:
"Please pull from
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
to get these changes:"
so that I don't have to hunt-and-peck for the address and inevitably
get it wrong (actually, I've only gotten it wrong a few times, and
checking against the diffstat tells me when I get it wrong, but I'm
just a lot more comfortable when I don't have to "look for" the right
thing to pull, and double-check that I have the right branch-name).
Please use "git diff -M --stat --summary" to generate the diffstat:
the -M enables rename detection, and the summary enables a summary of
new/deleted or renamed files.
With rename detection, the statistics are rather different because
git will notice that a fair number of the changes are renames.
You can form your own opinions as to why Linus is angry with them.
I dislike Github pull requests because the Github interface does not allow any option for merge other than the branch name from which the requester created the request. I.e., the receiver can not merge the pull request onto a different, more appropriate branch, from the one the requester used.
Plain git can do so. The only workaround for this broken interface on Github is to extract the pull request, manually perform a command line merge locally, and push the changes back up (now in the correct branch). Thankfully, if done right, Github does recognize and clear the pull request. But that is a lot more hassle than should be necessary.
In the first camp you have those who think process is important and that it and commit messages in particular are part of the product. Linus Torvalds apparently is such a guy so it makes sense for him to require carefully formatted commit messages as much as it makes sense for me to require four spaces indentation in the code. Apparently Github's tools makes it hard to enforce such strict rules.
In the second camp you have those that consider only the end result, the source code important. For them commit logs are just one tool of many to help them produce bug free code. Consequently, they don't give a flying fuck whether the commit messages uses hard line breaks at the 72 character mark or not. The prettiness of the logs is unimportant.
I'm definitely in the second bucket. Writing commit messages is no fun and adding anal rules to the process makes it even more unfun. Of course, sometimes it is necessary to explain what you are doing, and then you do that to the best of your effort.
Btw, the best way to drive away contributors from a project is to reject patches for silly commit log message formatting rules violations. Linus can get away with it because there are so many that want to contribute to Linux, but projects with lower profile than his would falter pretty quickly if they were so strict about the rules.
You move from the second camp to the first camp when you have to read massive amounts of code and commit logs.
You are also right. Small projects don't need them because you have to time to to look trough the few changes fast.
Linux development would not go as smooth if it would not have rules (that are quite minimal btw.). If everyone would commit code with different indentation and these changes would constantly end in git, it would be chaos. Same for commit logs. It does not matter at all for those who are contribution only time from time, but if it's your everyday job to read trough them it's important.
He says:
"Btw, Joseph, you're a quality example of why I detest the github interface. For some reason, github has attracted people who have zero taste, don't care about commit logs, and can't be bothered. The fact that I have higher standards then makes people like you make snarky comments, thinking that you are cool. You're a moron. Linus"
When properly done, aggressiveness and cursing at people is way to emphasize things. In the scale of emphasis it falls somewhere below passive aggressive and using all caps.
Here is the example sentence in standard hacker rudeness scale:
0. Please fix this.
1. Fix this now, you moron. <-- Linus
2. I guess, we don't use this until you find way to fix this. Maybe I help with FreeBSD project meanwhile.
Why should we not spit on people who don't care about commit logs. When Linus is insulting person, that stings a while. Shitty developer is insulting and harassing everyone day by day.
Being honest and aggressive is way to get people change their behavior or leave.
I'm not saying that Linus is right here. I'm just pointing out that rudeness can be the right way to deal with people who don't take a hint.
Quoting from linux/Documentation/SubmittingPatches.txt
So there you go.