6 ms·

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 viewin

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 14y ago
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".
- Jare 14y ago
  He explains it here: https://github.com/torvalds/linux/pull/17#issuecomment-5659933 https://github.com/torvalds/linux/pull/17#issuecomment-56599... In particular, "the quality of stuff I have seen from people who use the github web interfaces has been so low that it's not worth my time."
- normalocity 14y ago
  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.
- mjschultz 14y ago
  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 14y ago
    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.
- technomancy 14y ago
  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.
  - tytso 14y ago
    I really don't see it as him being a prima donna. Some of the deleted comments from the github forom removed the truly trollish comments that he was responding to, such as "Linus's shit doesn't stink." My take on it is that there are a very large number of morons out there on the internet, and just as you don't want to hire B or C people in a startup, you don't want morons trying to contribute to an open source project. B and C people add negative value to a company, not just with their bad ideas and bad code, but in wasting the time of the A people in cleaning up after their bad ideas and bad code. Why does anyone think it will be any different in an open source project? Hence, if you have someone who has demonstrably acted like an idiot, you really are better off driving them away from the project (fortunately many of these idiots have thin skins, and can be easily driven away). There is a risk that someone who isn't a moron and who sees someone else who does deserve this treatment might decide to go away, but the chances of this are low, especially if you treat non-idiots well. Also, just from a probability point of view, especially on the internet, unfortunately the morons vastly out-number the non-morons (see 4chan for proof of this :-), so if you don't do this, you will get swamped. There's also the probability that someone who acts like a moron could be trained how to be less moron-like, but personally, someone who says something like "Linus's shit doesn't stink" is probably someone I would treat as a NO HIRE in an interview situation; maybe they could learn, but you don't take those chances when interviewing potential engineers for a startup. They can learn at some other companies, and try again to go through the interview process later after they've gained some experience.
jasonwatkinspdx 14y ago
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.
- MBlume 14y ago
  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?
  - jasonwatkinspdx 14y ago
    Because the majority of our software ecosystem does not in fact treat wrapping this way. Moreover, the common solution trivially handles both situations.
- dredmorbius 14y ago
  Linus actually addresses that specific point, several times, in the original discussion thread. Please refer to his comments.

kstenerud 14y ago

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

Jare 14y ago
He explains it here: https://github.com/torvalds/linux/pull/17#issuecomment-5659933 https://github.com/torvalds/linux/pull/17#issuecomment-56599... In particular, "the quality of stuff I have seen from people who use the github web interfaces has been so low that it's not worth my time."
normalocity 14y ago
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.
mjschultz 14y ago
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 14y ago
  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.
technomancy 14y ago
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.
- tytso 14y ago
  I really don't see it as him being a prima donna. Some of the deleted comments from the github forom removed the truly trollish comments that he was responding to, such as "Linus's shit doesn't stink." My take on it is that there are a very large number of morons out there on the internet, and just as you don't want to hire B or C people in a startup, you don't want morons trying to contribute to an open source project. B and C people add negative value to a company, not just with their bad ideas and bad code, but in wasting the time of the A people in cleaning up after their bad ideas and bad code. Why does anyone think it will be any different in an open source project? Hence, if you have someone who has demonstrably acted like an idiot, you really are better off driving them away from the project (fortunately many of these idiots have thin skins, and can be easily driven away). There is a risk that someone who isn't a moron and who sees someone else who does deserve this treatment might decide to go away, but the chances of this are low, especially if you treat non-idiots well. Also, just from a probability point of view, especially on the internet, unfortunately the morons vastly out-number the non-morons (see 4chan for proof of this :-), so if you don't do this, you will get swamped. There's also the probability that someone who acts like a moron could be trained how to be less moron-like, but personally, someone who says something like "Linus's shit doesn't stink" is probably someone I would treat as a NO HIRE in an interview situation; maybe they could learn, but you don't take those chances when interviewing potential engineers for a startup. They can learn at some other companies, and try again to go through the interview process later after they've gained some experience.

jasonwatkinspdx 14y ago

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.

MBlume 14y ago
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?
- jasonwatkinspdx 14y ago
  Because the majority of our software ecosystem does not in fact treat wrapping this way. Moreover, the common solution trivially handles both situations.
dredmorbius 14y ago
Linus actually addresses that specific point, several times, in the original discussion thread. Please refer to his comments.