Why is Linus Torvalds angry with Github's pull request interface?
5 comments
I'm going to assume this is a plea for help?
Quoting from linux/Documentation/SubmittingPatches.txt
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.
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.
Doesn’t he give detailed information on why Github’s interface appears inferior to him, e.g. in https://github.com/torvalds/linux/pull/17#issuecomment-56599... ?
Free software devs fall into two camps.
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.
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.
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 is a rude person.
Look at his comment in the same thread: https://github.com/torvalds/linux/pull/17#issuecomment-56599...
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"
Look at his comment in the same thread: https://github.com/torvalds/linux/pull/17#issuecomment-56599...
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"
The Linux Development Community is known for being overly aggressive. Torvalds more than most.
If you say something stupid or do anything wrong, they will hate for for it and call you an idiot.
It's not necessarily a bad thing. I guess it may help prevent lesser programmers from contributing code to the kernal.
If you say something stupid or do anything wrong, they will hate for for it and call you an idiot.
It's not necessarily a bad thing. I guess it may help prevent lesser programmers from contributing code to the kernal.
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.
3. I need you to fix this NOW.
4. I NEED TO YOU TO FIX THIS NOW!
5. I NEED YOU TO FIX THIS NOW, MORON!
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.
3. I need you to fix this NOW.
4. I NEED TO YOU TO FIX THIS NOW!
5. I NEED YOU TO FIX THIS NOW, MORON!
But is he right?
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.
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.
I am new to git and github. And what is his preferred way of doing pull request?