
Linus Torvalds won't do github pull requests - quellhorst
https://github.com/torvalds/linux/pull/17#issuecomment-5654674
======
rit
Fun Fact:

If you tack '.patch' onto the end of a Pull Request you get a 'git am'
compatible patch file complete with the email address that Linus complains is
missing ;)

<https://github.com/torvalds/linux/pull/17.patch>

EDIT: I should note this works on any _commit_ as well. Take this commit from
Casbah (the Scala MongoDB driver I work on) -
[https://github.com/mongodb/casbah/commit/990a36fbde69db26689...](https://github.com/mongodb/casbah/commit/990a36fbde69db26689b9bcf680719928f6c11c8.patch)
\- removing .patch gives you the normal web based github commit page.

~~~
augusto_hp
Great! Didn't knew that! How did you get to know that?

~~~
spicyj
IIRC they had a blog post about it at some point. You can also add .diff to
get a slightly different format.

------
mindstab
The man wrote git for use on the Linux kernel. Trying to argue with him about
how to use git with respect to your tiny patch to the Linux kernel seems...
like missing the point on a great many things. The rules for submitting kernel
patches are laid out in great detail. Do you really thing arguing with the
gatekeeper is going to change anything?

~~~
jasonwatkinspdx
I think people are arguing for two reasons:

1.) Linus is being a bully. There's a difference between speaking your mind
openly and using rhetorical force to invalidate contrary views.

2.) The kernel requirements can be whatever those who control the kernel
demand. That's just common sense. Making the leap to declaring that only one
text wrapping approach is objectively correct is delusional.

If Linus simply said "The github pull request interface makes it impossible to
follow the kernel commit guidelines, and we are not open to reconsidering
those guidelines" there'd be no argument.

~~~
natep
2\. He clearly stated his reasons why his text wrapping approach is
objectively superior (not correct). If you think he's delusional, point out
the criterion he has failed to consider, or explain how some other system
meets any of his criteria better.

In response to the pull request he did simply say "I don't do github pull
requests." and explained why, and basically said he would if github supported
commit messages in the appropriate style. He never insulted the pull
requester. He called whoever is this "Joseph" person a moron, and now we have
no idea why.

~~~
benatkin
Apparently "Joseph" deleted his comment (very un-git-like of GitHub to make
deleting a comment without a trace so easy). I checked all the other
participants above where "Joseph" posted and found a Dan, but no Joseph.

~~~
DCoder
Reddit[1] found the "Joseph" in question, his comments are still visible in
his public activity stream: <https://github.com/pirtlj>

[1]
[http://www.reddit.com/r/programming/comments/tionj/linus_tor...](http://www.reddit.com/r/programming/comments/tionj/linus_torvalds_doesnt_do_github_pull_requests/c4n49r8)

~~~
natep
Thanks, good find!

So, if @pirtlj said that in response to Linus's first comment, then he was way
out of line, and something should have been said. Maybe Linus didn't say the
exact right thing, but I doubt I would have been able to say much better.
Hopefully @pirtlj learned more than that he shouldn't have said anything
(although even that would be a good thing, I think)

------
marcamillion
I don't mean to be overly critical, but is it just me or are the 'godfathers'
of computer science starting to sound like cranky old men?

I mean....ok....this pull request being inferior to the way HE (the creator of
Git) imagined it (or implemented it) is a bit petty imho.

What's with the complaining? I am sure this is not the first time I have heard
him complaining about something on Github or some other 'new technology'. The
same goes with Crockford and his semi-colon.

Edit: Although, I must confess that it is annoying when the creators of a
service that you use totally blow off your suggestions (esp. when that service
is built on your own creation).....so I am torn on this one. Still has the
'annoying old man complaining feel' to it though.

~~~
bithive123
It's all about context. To someone who only knows PHP the opinions of most
polyglot programmers seem cruel and elitist. Put me in a room full of Moodle
developers and everyone will come away thinking of me as "that cynical guy who
is always trashing everything we do".

Are people so averse to acknowledging the bounds of their own experience that
they discount other views over a hint of emotion? Does every cantankerous
remark need to be taken so personally? Why is it so important to be
inoffensive? Does all advice need to be delivered as positive encouragement?

~~~
marcamillion
I think it is subjective - unfortunately.

With a bigger microphone comes greater responsibility.

I am not taking Github's side on this particular issue - but this issue struck
a bigger tone (for me)...where I have seen those with a larger microphone (by
virtue of who they are) seem to be complaining louder (publicly) in recent
history. It could just be that their microphone has gotten louder - but if it
has, to a large extent they have a responsibility to be more conscious.

Imagine if Obama complained about the food at a bakery down the street that he
went to - that would effectively kill that establishment. As a patron, does he
have a right to complain about disgusting food? Absolutely...as someone with
the largest pulpit in the world? Definitely not. There are other means he
could use to get his message across.

Then again, I am not comparing Obama's pulpit to that of Torvalds, but I think
it makes the point sufficiently.

~~~
bithive123
Yes. Opinions, passionately delivered, will correctly be perceived by some as
inflammatory or unfair.

Each observer can decide if the remark is appropriate or not. We are more
likely to forgive Linus on his "home turf" than Obama singling out a
particular business.

This highlights the problem, not everyone thinks critically about context so
you end up with people writing off good practices because the advocate was
mean and/or avoiding a bakery because the president complained.

------
spinlock
Man, now I feel like a total hack. I love the github pull request. I do insist
that my devs use a good style (i.e. first line is a summary and wrap at 80
chars) but I love the user interface for looking at diffs and doing a code
review. I had no idea it was inferior until reading this and now I find myself
in the awkward position that I don't care. Have I really become the guy who
values an efficient team process more that adherence to esoteric
specifications. God, I can't believe it's come to that.

~~~
ajross
The pull request as a mechanism for "here are some changes to look at" for a
small project isn't the same thing as "Here are the USB stack changes for the
3.4 merge window".

The kernel has a mature, rigorous and well-defined development process[1].
Things that don't fit well into that model just aren't going to be successful,
even if they work well in other contexts.

[1]
[http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git...](http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=tree;f=Documentation/development-
process)

~~~
ajross
It's also worth pointing out that the "pull request" in question here was a
2-liner addition of a USB device ID that should have gone to a subsystem
maintainer anyway.

------
tytso
I don't understand why people are upset with Linus's writing style. I
considered what he wrote to be quite polite. He was merely stating his
standards in terms of what he would and wouldn't accept (and github pull
requests are on the "won't accept" list). He even explained why he wouldn't
accept it.

Furthermore, the patch was deficient in other ways. (a) it was missing the
Signed-off-by: header, and (b) it should have been sent to the linux-bluetooth
mailing list or one of the Bluetooth maintainers, with the linux-bluetooth
mailing list cc'ed.

~~~
laughinghan
I think it was comments like "The fact that I have higher standards then makes
people like you make snarky comments, thinking that you are cool.

You're a moron." that people thought impolite. The comment he responded to
appears to have been deleted, however, so I can make no judgement about how
appropriate that was. I'd like to think it was completely appropriate -- I do
agree with you overall that his other comments were reasonably polite.

~~~
saurik
I don't remember the exact wording of the comment that was deleted, but I did
see it and I remember it making me feel very angry, despite that I wasn't even
involved in the discussion. My personal belief is that Linus' response was
quite classy in comparison, especially given that others in the conversation
weren't stepping up to take issue with the comment.

------
mjs
It's instructive to read Linus's commits to his hobby project "subsurface":

<https://github.com/torvalds/subsurface/commits/master>

Even if I can't code like Linus, I can at least try to write commit messages
like his…

~~~
why-el
It always puzzled me why his commits (and in fact standard commits) ought to
start with a verb that is not in its past form. When I started using git four
months ago (such a newbie), I would write something like "Fixed this" instead
of "Fix this". Anybody with more insights on this? I am just curious.

~~~
gchpaco
If you think of the change set as the subject, so the question is 'what does
this do?' and the answer is 'fix X' then it makes more sense. Past tense
suggests you might be thinking of it as a journal or something that you're not
supposed to do with git due to rebase etc.; each commit ought to stand on its
own.

That said I don't think this is significant enough to add up to a compelling
reason either way.

~~~
nirvdrum
Sorry, pardon the ignorance, but how does past tense imply something that
would be affected by rebase? It may not be linear history, but it definitely
happened in the past. I guess I always looked at more as: "here's a patch",
"what did you do?" If it's just a tomato/tomato thing (yeah, that doesn't come
out well in text), just let me know.

~~~
gchpaco
Because rebase, and rebase -i especially, gives you the ability to break your
patches into discrete this-one-one-goddamn-thing patches (which is awkward in
a "oh, you committed it? Then you committed it forever" SCM like Perforce or
SVN), you should do so. It makes it a lot easier to review than the "so this
does X, but also fixes some syntax errors and adds logging" style. And that
means you should make the patch comment reflect what it is doing. Some errors
here are inevitable but it's something to which I aspire.

Edit: to be a little clearer; your traditional SCM has a write-once-never-
change model for the trunk of development. This has a problem in a peer review
situation, and the problem is this: I may go forth with the best of intentions
to decompose things into discrete patches. But when you get down to brass
tacks, changes to the system tend to happen in any given order--you might
discover a latent bug when testing your feature that has nothing to do with
your feature. Now you have two choices: you can wait and commit nothing until
everything is great, which means you're not integrating with the mainline,
which means that integrating will be incredibly painful, which leads to locks;
or you commit as it comes in the moment, which is much better for integration
and much easier to back out partial changes and generally get all of the non-
backup elements of an SCM, but which is the very devil to peer review. With
rebase -i, it is quite easy to commit in the second style _in the moment_ and
then clean them up for peer review later; that is the ability to revise
history means you can make decisions immediately without worrying that they
will be cast in stone forever and ever anon.

I wasn't always this much of a hardliner on the subject, but my current job
uses Perforce as the main SCM and I have realized that I disagree with almost
every decision Perforce makes across the board. I still use it, because any
SCM is way better than no SCM and I don't want to explain git to everyone
else, but my actual development occurs with git-p4.

~~~
nirvdrum
Thanks for responding. I don't think I necessarily agree, but then again I
rarely rebase because I distinctly dislike rewriting history, but I think I
understand the rationale a bit better.

------
zobzu
Well here's the thing: Linus is right.

Linus does not hesitate to criticize and always think about things before
declaring them cool.

Oh he makes errors like everybody. He's usually not always very nice in
messages (read LKML and you'll understand). But he's usually right and he's
usually not writing random things because "it is trendy".

So GitHub is trendy. Linus doesn't care. Linus cares for the good features and
pull isn't one of them in his eyes. And then again, I think he's right. Pull
in GitHub is crappy.

But what's missing from his message is the _reason_ why the GitHub pull is
crappy. I'm sure he knows, but he's using half words. Here's the reason:

If GitHub enforced proper pull messages PEOPLE WOULDN'T USE IT. Why? Because
it's the easyness to fork and pull that make GitHub successful. So you see,
pulls have to be _DEAD EASY_. And that means also "single text field, no
enforcement of anything".

So yeah. GitHub won't fix it, because it'll be bad for their business.

~~~
ryanbrunner
I really don't understand why GitHub _should_ fix it, though. It's not like
it's impossible to put on a README or something else in a prominent place that
pull requests need to follow certain standards.

With Linus' current work flow (pull requests via e-mail), it's still perfectly
possible to have a horribly structured pull request, and so they've added on
rules beyond what the technology can do for how pull requests ought to be
formatted. I'm failing to see why the same rules can't be applied to GitHub.

Linus _invented_ Git, and it's perfectly possible to have single character
commit messages in Git. I'm not quite sure why it's a failing of GitHub that
it takes a similarly loose approach to how it deals with pull requests.

------
lobo_tuerto
I hope the github folks get involved in this. I'm specially interested in what
they have to say about why they decided to go with what Linus calls _their own
totally inferior version_.

Love this no-nonsense style, but let me say that it's no only the style, but
that Linus has enough on his side to back it up.

~~~
bermanoid
You only love the style because he has enough on his side to back it up.
Anyone else that acted like Linus does on a regular basis would be considered
childish and arrogant.

I'd take Github's version of any feature, any day, over the official git
version, any time they differed - Git is a notoriously user-hostile piece of
software interface-wise, and pretty much the only thing it has going for it on
the usability front is Github.

~~~
bad_user

         Git is a notoriously user-hostile piece
         of software interface-wise
    

It's funny you say that, because Git is the only version control system where
working with branches, forks and merges in big projects is not only doable,
but in 90% of the cases painless. You can't really appreciate Git until you've
tried doing the same tasks in Perforce, SVN and CVS. No other similar software
has the same painless approach to branching and merging, not even other
distributed systems.

Also, its interface is hostile because it requires the user to understand a
little about its internals. You may disagree that this is good design, however
it gives you unprecedented control over the repository, which you need often
when the shit hits the fan. Also, Git is freakishly fast and efficient. Much
like C, an interface done with taste, but that doesn't appeal to those with
weak hearts. And the fact that such projects as Linux are maintained with Git,
projects which have a huge number of contributers, it's a true testament to
Git's awesomeness.

And btw, considering how version control is one of the most important tools at
your disposal, if not the most important in big teams, stop reading those SVN
2 Git tutorials and go read a freaking manual. It's worth it, because you'd be
amazed at how much power it has under the hood.

~~~
viraptor
> Also, Git is freakishly fast and efficient. Much like C, an interface done
> with taste

I don't agree with the second claim and the first one does not explain it
being that way. What is so tasteful about this:

    
    
        # delete
        git remote rm ...
        git branch -D ...
        git tag -d ...
        git rm ...
    
        # rename
        git remote rename old new
        git branch -m old new
        # can't git tag ...
        git mv
    

No - it may be useful, it may be fast, it may be efficient. But the interface
sucks completely and is very inconsistent both between the commands and in
what is each command's responsibility.

~~~
bad_user
First of all, all of these commands make perfect sense to me. I don't know why
exactly, but I've never used a version control system that made more sense
than this. I never really felt like I'm home with Perforce and SVN. Neither
with Mercurial, although Mercurial is better than most.

    
    
        git remote rm
    

This deletes the reference to a remote repository. The difference between Git
and SVN here is that in Git you can have _multiple_ remote repositories with
which you can communicate.

This comes in handy when pulling and pushing to/from multiple people. Imagine
swapping code between you and your colleagues, doing experiments, doing code
reviews, and so on. It also comes in handy when you're dealing with Heroku, or
when you've got an "open-source" core that's pushed to GitHub and another
branch with proprietary additions that you push somewhere else.

Also, all commands for managing these repository references start with "git
remote" and to find out how to do something with them you just do "man git-
remote".

    
    
        git branch -D
    

This deletes a local branch. It has nothing to do with the above. It does not
use "rm" because that can be the name of a branch and this command is heavily
overloaded.

    
    
        git tag -d
    

This deletes a tag. It is consistent with the above command, as "git branch
-d" (lowercase D) is also supported, but uppercase D means that the deletion
is forced, even if the branch was not merged. Again "rm" was not used, as that
can be confused with the name of a tag.

    
    
        git rm
    

Deletes a file, but you don't have to use it. If you're confident about your
editing skills, you can just commit all the deletions with "git commit -a ..."
... git will also be smart enough to detect a file rename, even though you did
a deletion + addition.

"rm" is also the name of the command that does the same thing in Unix, being
associated with the removal of files.

    
    
         git remote rename old new
    

As I said, "git remote" manages references to remote repositories. This just
renames the reference named "old" to "new".

You could say that they should have used "mv", like in the case of "git mv",
however this is not a "move" command. This is just plain renaming.

    
    
         git branch -m old new
    

This renames the local branch named "old" to "new". It is indeed inconsistent
with the others, but that's because the "git branch" utility has been
overloaded a lot. This command does confuse me from time to time.

    
    
         git mv
    

Like in the case of "git rm", this command does a "mv", while registering the
action in Git. It is also not necessary if you're doing a "git add . && git
commit -a".

"mv" does make sense here, as it is the name of the Unix command for moving
files.

And a final tip for beginners: use the "man" pages. In a terminal input any of
the following commands when you need help ...

    
    
        man git-remote
        man git-branch
        man git-tag
        man git-rm
        man git-mv
        man git-push
        man git-pull
        man git-reset
        man git-checkout
        etc...

~~~
viraptor
Sure they make sense if you have it in front of you and want to know what they
do. They stop making sense when you want to write them - why do you have to
have different way to deal with each type of an object. Either stick to -d/-D
convention, or rm/rm --force, or delete/delete --force, or something else...
just don't mix up calling conventions just because you operate on a different
kind of object. Same goes for listing things, renaming, etc.

My point was about inconsistencies rather than not being able to figure out
which command did what.

------
bitops
From his "subsurface" project README.

 _Also, please write good git commit messages. A good commit message looks
like this:

Header line: explaining the commit in one line

Body of commit message is a few lines of text, explaining things in more
detail, possibly giving some background about the issue being fixed, etc etc.

The body of the commit message can be several paragraphs, and please do proper
word-wrap and keep columns shorter than about 74 characters or so. That way
"git log" will show things nicely even when it's indented.

Reported-by: whoever-reported-it Signed-off-by: Your Name
<youremail@yourhost.com>_

------
fdr
I also do not care for the pull requests, for much the same reasons. I like
there is a way to bring a branch to a maintainer's attention and updating its
commit range in event of updates before it is accepted, but the way messages
that result from merging in the code is irritating, so I end up just using
"git pull" to do the trick once the branch looks good to me.

------
memset
Can someone point me to the tool that comes with git for pull-request
functionality?

~~~
onedognight

        git request-pull
    

If you'd like to see an example, this will generate the text of a request
sending the top few commits in your repository (assuming the origin / master
convention)

    
    
        git request-pull master^^^^^ $(git config remote.origin.url)

~~~
xnxn
A tip - you can use master~5 instead of master^^^^^.

~~~
onedognight
Thanks! I expected someone might save me the time of looking that up.

------
jamesflorentino
For people wondering why Linus said "You are a moron" to a particular user
named "Joseph": The comment he was replying to was deleted.
<https://github.com/pirtlj>

in one of his comment, "I did not realizes that Linus' shit does not stink.
Thanks for clearing that up..."

Apparently, even if a comment gets deleted from a Github discussion, it still
sticks to your public activity.

------
happycube
Considering Linus _created_ git, if I were running github I'd tend to listen
to whatever he had to say about it...

~~~
eridius
Devil's advocate:

Considering GitHub _popularized_ git, if I were in charge of git I'd listen to
what the GitHub guys have to say about it.

~~~
mindstab
Depends where. Projects like the linux kernel (obviously), Xorg and Firefox
had all moved to git before github ever showed up. It was well on it's way to
popularity all on its own merits

~~~
zbowling
Firefox uses doesn't use git.

------
corford
Jesus, watching some of the little snowflakes on here whining about how Linus
chooses to run his repository is seriously disheartening. When did the the
tech community get infiltrated by so many prima donnas and drama queens? If
you have a problem with Linus' style or how he chooses to use the tool he
made, build an alternative (if you can...) or swap over to a different stack
and get on with your life. Stop whining.

------
alain94040
It's 2012 and we're still arguing about line breaks and 80-character lines?

~~~
jarek
It's 2012 and Gmail can't consistently reflow lines in emails between its
flagship web client and its flagship Android client... so yes, it would appear
so.

~~~
drivebyacct2
What?

~~~
drivebyacct2
Okay. Thanks for the downvote, so I'll ask again, "what?". I don't know what
you're talking about and have never experienced anything that might fit that
description. Can you offer an example.

~~~
jarek
Sorry to see you downvoted.

Reflowing refers to reconstructing lines broken by line wrapping. Here's the
example I was referring to: Grab a couple of unwrapped paragraphs of lorem
ipsum (make sure there's no explicit newlines) and email them to yourself as a
plain-text email using the desktop web gmail interface. You will notice that
when you open the email in your inbox, it shows up with line breaks - Gmail
sent it with explicit newlines after ~80 characters. (Use Show Original if you
want to confirm.)

Now open the same email in the Gmail app on Android (I'm using Gmail 2.3.6 -
the newest available on my Androids 2.2 and 2.3.6). My Android screen, like
most smartphone screens, isn't wide enough to hold all 80 characters in one
line, it's more like 50 or 60 characters. Gmail wraps the email to fit, which
is expected and desirable. The problem is it keeps the original linebreaks at
80 characters, resulting in two linebreaks. Every other line is short at 20 or
30 characters and the email looks very jagged. Reading it is very
uncomfortable. It gets really messy when you have quoted text, particularly
with interleaved response style.

There's actually a whole bunch of standards or semi-standards and techniques
around doing this kinda stuff. Standalone mailers have been doing reflowing
and format=flowed for a while now. Sad to see Gmail drop the ball on this.

------
dhconnelly
antirez via twitter: "Linus, I'm with you. Preserve your bastion of code
quality as it's something rare and rapidly fading away."

<https://twitter.com/#!/antirez/status/201065752395124737>

~~~
nwmcsween
Linux and code quality? I think you may be confused.

~~~
chj
Please name one project out performing Linux kernel in terms of your
definition of code quality. I'd like to have a surprise.

~~~
nwmcsween
Define code quality: braindead GNU extensions such as nested functions - Linux
uses that, How about the separation of DM and MD due to ego's, how every
driver without a lib (such as libata) warranting a few exceptions has to
rewrite boilerplate for basic things - frame buffer drivers are a good
example. How about the syscall bugs - look into glibc if you feel like gouging
your eyes out or jemalloc for more tame code. Linux itself is more an
ecosystem of code and not a single project some parts are good while others
are very very bad.

~~~
adobriyan
C nested functions were explicitly banned from Linux.

What are the others?

------
trustfundbaby
I get the point he's trying to make and completely agree with it, but the way
he presented his issues just made me lose respect for him a little bit ... I
just wish someone that respected was able to present his views in a way that
younger developers could emulate.

I can't help thinking tons of "rockstar/ninja" developers out there are going
to embrace this abrasive style of disagreeing with people and totally
rationalize it by thinking well "that's how the guy who wrote Linux does it,
so that's how I'm going to do it"

Someone that well respected should (and this is my opinion) never have to
reach to the level of addressing someone so far-removed from the heights
they've attained, as a 'moron', when simply ignoring them would do. But I'm
nobody important, so what the hell do I know about anything ...

~~~
gft
This was mentioned as a concern when Steve Jobs died:that budding ninja
technologists would try to emulate his puportedly nasty management style.

Fortunately, I think this sort of nastiness is self-limiting. The only really
egotistical, nasty rock star I ever worked with destroyed himself, much to the
delight ( and with some assistance from) his colleagues. I think that would be
be a far more likely outcome than a nasty rock star continuing their ascent
with a bad attitude.

------
rumcajz
That's pretty relevant comment. GitHub pull request system is great if you
want to attract a bunch of script kiddies to participate on your project. For
serious work, not so much.

~~~
nupark2
I would say the same about github's forks-as-top-level-entities system.

Forking a project is a huge deal. Forking a git repository is no big deal.

Github does the former, and it encourages too-broad forks, and at the same
time, discourages coordination and contribution with the original project.
Nearly all forks should be short-lived and completely subsidiary to the main
_project_.

~~~
zoul
That's a lot of opinions and much less arguments (no offense). Would you care
to explain the motivations behind the opinions?

~~~
nupark2
Forks -- as top-level named entities -- draw attention and resources away from
the original project, possibly leaving both projects with too-few resources to
survive afterwards.

This is why "forking" an open-source project was considered a nuclear option
prior to the emergence of github.

I rarely even get pull requests from people forking my code on github, and
when I do, they almost never have bothered to discuss with me prior to
implementation. It's a relatively recent phenomena that is largely encouraged
by the tools.

------
gte910h
Maintainer of a project doesn't like a tool some people like to use. News at
11.

Seriously. Just dont' send this particular maintainer pull requests that way.

~~~
astine
This maintainer is a little more notable than most... And his opinion is a
little more relevant :)

~~~
gte910h
That's the thing about science or really any discipline where results is more
important than anything else.

It's not really. If any other maintainer of a project finds they're cool with
pull requests from github, then it's a fine tool for those projects. This guy
runs a project which is an outlier in it's size, and which is also a far older
project than most of what github hosts.

Now if his criticism has useful facts, that MIGHT be useful, and it does: The
github format has fewer bits of info. Could some of those bits of info be
important? Maybe. I didn't sense a genuine, measured analysis, but instead a
rant from a maintainer about something that's not working for his project. Nor
did I see a counterpoint from github why their tool does it the way it does.
There may be real design decisions there, ones that might be better answers
than what Torvalds has, especially for projects far smaller than Torvalds.

Don't let Torvald's status as the maintainer of the Linux kernel (and creator
of git, to do that task) make you forget he's also paid attention to because
he's famous as well as a useful contributor. Fame doesn't make you more right,
just more adored. His ideas still require critical analysis from the rest of
us.

------
goatslacker
I have to agree with Linus on this and it's nice that he's taking time to
write out his thoughts in public.

GitHub commit messages can be really ugly. I'm guilty of this and it's not
something I'm proud of. I think the small improvement they did a while ago
with the display of commit messages is a step in the right direction, I wish
they would apply that same style to the web interface when composing commit
messages.

edit: A good fix would be a way to turn off pull requests for projects or at
least redirect users on how to send pull requests.

------
DanWaterworth
What, Linus found something he doesn't like?

~~~
bad_user
Don't forget SVN: <http://www.youtube.com/watch?v=4XpnKHJAok8>

------
alexchamberlain
I agree with Linus on a lot of things, but I wonder sometimes if he rubs
people up the wrong way occasionally.

~~~
laconian
He makes no bones about it. Git got its name because Linus thinks of himself
as a git.

------
mike626
Extremely relevant criticism. It appears to be a rather simple problem for
Github to resolve.

------
ilaksh
Maybe github can make it easier to send messages in reply to a pull request,
or even show an email field there. Having people type out their email into the
pull request is not the best way to handle that on the web interface I don't
think (although practically speaking if you want to use email it is perfectly
reasonable to make that a rule for your project until there is a feature like
that for git and github). Ideally git itself could make it convenient to view
that as a separate field with the pull request.

I am also pissed when someone ignores a feature I have written and redoes
something without good reason.

Torvalds probably doesn't have time to handle a whole bunch of git pull
requests, and most of them from github probably have problems or aren't
important so this rule probably helps him a lot, practically speaking.

But obviously the people at github should really carefully analyze what he is
requesting and if possible this could result in some minor improvements in
that part of the github interface or git or both.

I don't know much about the Linux kernel, but I don't think that this type of
driver information should be in such a centralized place and controlled by an
individual or small group of individuals.

------
delinka
It's Linus's repository and he can do things the way he wants. Stop whining.

------
kstenerud
So what exactly is deficient with github's approach to pull requests vs git
pull-request?

------
DigitalSea
As genius as Linus is, the dude needs to take a couple of shots of harden the
f*ck up. I'm sick of his school girl rants and complaints. For such a well-
known figure head in the open source/computing industry he sure does complain
a lot.

------
fictorial
How on Earth is this drivel at the top of HN?

~~~
daenz
It's nearly the tech equivalent of a tabloid article. It sells because it has
level of entertainment value, not found in "why fictorial won't do github pull
requests"

------
giis
I can see two stupid comments by pirtlj (<https://github.com/pirtlj>)

>pirtlj commented on pull request 17 on torvalds/linux a day ago Ouch my
feelings are broken... I just wish you would live up to your image, but then
again you're just an imperfect human too.

>pirtlj commented on pull request 17 on torvalds/linux a day ago I did not
realizes that Linus' shit does not stink. Thanks for clearing that up...

------
methodin
The one thing I'll have to give credit to Linus for is that even if people
continue to post absurd comments after his original lengthy counterpoint, he
will delve into a more polite rhetoric and continue to explain his point, over
and over. It's quite the opposite, in fact, of many people who write online
where typically the end result is simply escalation or continued fervor.

------
stefanve
Github should implement a tempting system for commit messages that way every
project can enforce there own standars. And those templates should be
shareable, like a template repository so new and existing projects can opt to
use one of the exciting ones.

problem solved :)

------
gianpaj
i am i the only one who's reading Torvald's comments with David Mitchell's
voice? <http://www.youtube.com/watch?v=PqSZEGj-SuI>

------
labanro
As long as Linus patiently explained why he doesn't accept guthub pull
requests, it seemed ok. But calling someone a moron for it, that kinda hurts
the community!

~~~
natep
He called someone else a moron, and that person deleted their comment. For all
I know, that person's behavior was worse

------
zbowling
Some insightful comments on the github are getting deleted.

------
peterwwillis
If somebody invents a car and gives it to Torvalds, he'll call the designers
total morons if the blinker isn't at the height that he likes.

~~~
ocelotpotpie
This seems a bit misplaced. More like if Torvalds invents a motor and then
someone puts it in a car, he might complain if the motor doesn't run the way
he'd like. Which isn't entirely unreasonable.

~~~
peterwwillis
You're right, it's not unreasonable for him to not like it. He can dislike
anything he wants to. But that doesn't mean it's reasonable to expect the car
designers to change their car to suit his desires.

Github is not Git. It's a separate product which happens to _support_ Git, but
is not Git, strictly speaking. It's basically a social network for building
software. Far removed from the revision control software it depends on.

Complaining that the commit log isn't formatted in his preferred manner is
similar to an engine designer complaining that the car's ODB2 reports aren't
easy enough to read on his hand-held scanner. The engine designer can dislike
it all he wants, but if I was the engineering team who designed the whole car,
I wouldn't lose sleep over his dislikes.

------
yaix
GitHub, seriously, if Torwalds takes the time to point out a flaw in your
software, listen to him! Really.

------
cdvonstinkpot
These details matter apparently. I hope some of these improvements mentioned
will be implemented soon.

------
Revisor
Can anyone point me to best practices on writing (git) commits?

Or can you sum up yours here?

~~~
Revisor
Ok, found this, linked by Mr. Torvalds

[http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messa...](http://tbaggery.com/2008/04/19/a-note-about-git-commit-
messages.html)

------
zeropointmodule
This link would be better-titled as "Linus Torvalds pwns Github."

------
danieldrehmer
Isn't it funny when he signs his comments in the end?

~~~
kyberias
He's replying using email, that's why.

------
rogerclark
linus is a misanthropic blowhard. as a role model, regardless of whether he
signed up for it, he should be embarrassed at his behavior

------
codebungl
He's an engineer, he's just being definitive!

