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?

"You might have fun raging on the internet, but I think your goals would be better served if..."

He rightly responds:

"Umm. I think I've been able to reach my goals on the internet better than most people."

I believe in civility and courtesy in many areas, and Linus doesn't phrase things exactly as I would. But then, I don't have his responsibility or experiences, either - and while people can disagree about whether he expresses his thoughts in a polite manner, he certainly does so in a clear one.

The problem is that many times you can't have one thing without another. What I mean is that what Linus accomplished is also fruit of his character, you need character and be opinionated to do "git" for instance. Or even to make the Linux kernel the success and good piece of software it is, with many contributions: what separates a big software project to become a mess is character.

And the side effect is that he gets bored to listen at stuff that he thinks are silly. But see it from a different perspective, Linus is really, culturally an hacker, and not an academia professor. He is out there on github writing flames, arguing with people that have a github account completely clean and never wrote possibly a line of code at all. Exposing himself in the process to insults and so forth.

> He is out there on github writing flames, arguing with people that have a github account completely clean and never wrote possibly a line of code at all. Exposing himself in the process to insults and so forth.

I never understood why do people who have completely clean github accounts feel the need to preach to someone who has been programming for a long, long time and is the major force behind two of very significant, technically hard piece of software. This won't be the first time this has happened. In the "Linux on C++" thread, someone comes in and says "I am surprised you wrote git in C. Don't tell me C++ is bad. That's bullshit. Clearly I know more about this than you do". Or even the Eric Raymonds' post about "Curse of the gifted" - he comes out of nowhere and starts calling Linux names. The fact that other developers didn't even bother responding to his bullshit made me happy.

It's kind of Finnish way of expressing things. We might say "jos sä teet tän näin, voisit vetää ittes hirteen" (if you do it like this, you might want to hang yourself) without actually meaning it literally. We have less PC compared to many other countries and I still find it refreshing while living outside of the country.

Thanks, I don't like PC too much either, seems like hypocrisy most of the time. We also in Italy have little of it. I mean, instead of PC one should make sure to treat everybody in a fair way, but even if somebody is in a minority of some kind, if he/she does silly things, it is offensive to don't respond to it (possibly in a rough way) in the same way you would reply to everybody else.

Which is probably also the best example of why PC is dumb. For example, it's
hard to criticize Israel in German politics. At best, you'll be looked at in
funny ways, at the worst you'll be accused of being a nazi.

I never tried to imply that it's bad to be vigilant of fascism and right-wing
ideology. I'm very much among the first people who'd step up to prevent an
abomination like the Third Reich to ever happen again. I hold high respect for
people such as Stauffenberg and Dietrich Bonhoeffer, who risked and ultimately
laid down their lives fighting against the Nazis.

The motivation behind the German PC towards Jews and Israel isn't motivated by
that, though. Maybe it originally was, but these days it's but a way to silence
opposition to the questionable politics of the Israeli government. To be fair,
it's slowly fading out, probably not in small part thanks to the emergence of
the internet and new political movements, such as the Pirate Party.

Also, it's not like you can't criticize Israeli politics in Germany. It's
that you will see few politicians who are willing to do it openly, because
it's a minefield.

Although Linus is from Finland, he comes from the Swedish-speaking minority population there and his native language is Swedish. Sweden itself is pretty PC, but I don't know if that goes for the Finnish-Swedish as well, or if it is just Linux being Linus

My mother's husband is a Swedish speaking Finn and the cultures are quite the same. They are not Swedish people, they are Finns. The difference may be that they're a bit more international and also some studies say they enjoy life more than a typical Finn.

The whole country has two official languages, but Finnish-Swedish people use Sweden as their everyday language.

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.

IMO, the reason Linus is where he is today as an icon and at least some part of the reason we have a rock solid Linux to use across all our commercial and non-commercial projects is because Linus has strong opinions about how things should be.

Somehow, I don't know or have read about that many (if any) world-changing people, who also happen to be "so nice and understanding of others opinions" or "agrees to disagree".

I'm sorry, but there are indeed few ways to design a BMW and many ways to design a glob of metal that can't even move.

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.

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.

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)

Joseph said something snarky along the lines of "Oh I'm Linus Torvalds, I'm always right" -- I think Linus was overreacting, but he was at least a little justified. He seems to get very angry when people state anything more than what's based on "facts."

Did he say it was for 'all purposes'? He said 50 characters for the first line is ideal for shortlogs, and 72 characters for more verbose logs, etc, when viewed in a terminal. He also said that encoding word wrap at write-time is better because only the author knows how to appropriately wrap. As he said, sometimes lines go longer, if the commit message includes program output that shouldn't be altered. So, you can't relegate word wrapping to the presentation layer without an unreasonably smart algorithm.

I interpret his statements to mean that the git/kernel projects' commit message standards are objectively better on all the ways we know how to measure (or at least, for all of the most common ways of looking at commit messages). So again, if you want to disagree, your choices are to point out a criterion that is not being considered, or how this system is not better at a known criterion.

I don't think his goal is to have no arguments. His goal seems to be "fix this issue, god damn it!" And amusing rant can help bring attention to the issue (note tomayko comment in the original thread). I don't know about you, but the rant is entertaining to me.

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.

I don't see where he is being unreasonable. He made git with his specific method of managing the Linux source repository in mind. Now someone wants him to ignore part of his tool for their connivence and he said no.

He's not saying "we should all boycott GitHub because of it". He's not saying "they're idiots for doing this".

He's saying 'The Linux project works one way, GitHub doesn't support that way, so we're not using it, and they' won't change it'. That's it.

Full quote: "github is a total ghetto of crap commit messages and unreadable and unusable pull requests"

Conveniently left out the part most salient to Linus' argument? Linus repeatedly stresses that he thinks Github is great as a hosting service. It is the pull/commit functionality which he finds lacking.

If I could downvote you, I would. Seeing quote mining that bad on HN makes me sad. Or your english comprehension isn't that good, which is fine if it's not your first language, but still sad if it's your first.

Well, I'm glad you only misunderstood Linus, rather than were trying to deliberately twist his words. He never implied anything about the github team, or the site as a whole. Maybe you missed this comment [1][2]

> .. because I think github does some things very well.

> So sure, you may think I hate github. I don't. I hate very specific parts of github that I think are done badly.

> But other parts are done really really well.

> I think github does a stellar job at the actual hosting part. I really do. There is no question in my mind that github is one of the absolute best places to host a project. It's fast, it's efficient, it works, and it's available to anybody.

> That's wonderful. I think github is absolutely lovely in many respects.

> And that then makes me really annoyed at the places where I think github does a subpar job: pull requests and committing changes using the web interface.

It seems obvious to me that he likes GitHub a lot, and thinks the team behind it are very capable, and not at all braindead. This doesn't preclude them from having a braindead feature. Or a feature responsible for crap commit messages. Or a feature that is both.

[2] How fitting. Poor text wrapping support bites again. When I pasted the comment, it lost all line ending data, so I had to re-separate all the paragraphs (not sure if the fault is in GitHub, Win7 clipboard, FF, or HN).

Linus is kind of infamous for his rants and have been for years (especially on the mailing lists.. I've seen him tear into people for willful ignorance on the kernel dev lists more than once).

I've never really seen them as cranky because they're spot on. Cranky old men usually don't have anything other than opinion behind their rantings.. Linus can at least defend his position. Given his contributions to the world of technology, I'm more than willing to let the acerbic attitude slide.

Well...this debate always seems to come down to...do we let geniuses just do whatever the hell they want. The answer is...I am not sure.

Either way, there are many decisions that people make that comes down to style preference and sure the 'purists' might think it is a watering down of programming....but it makes it more appealing to new developers. I can see Torvalds ranting on Ruby as not a 'real' language....I don't know if he has done so...but I wouldn't be surprised if he did.

Today, he wants to manage his own repository with the vcs he created, in his own way, but tomorrow! - who knows if we don't stop him, probably rape and murder! We can't just let him do whatever the hell he wants!!!

In this particular case, nobody's coddling him because he's a genius, but because it's his repository that he's talking about whether or not to accept pull requests for.

Simply put, he has a rigid standard for pull requests, and GitHub isn't capable of adhering to it, so he can't (without making an exception) accept pull requests using the tool.

The rest of his ranting is mostly subjective, but I do find it amusing that pull requests in the number 1 git hosting service don't meet the creator's muster, and I'd love to know the reasoning behind their implementation.

For what it's worth, I didn't know of the in-built git pull request and I'm an avid Github user (though not submitting Linux kernel patches,) so in the spirit of optimism, airing this rant was informative to at least me, and probably many others.

Maybe you're missing the importance of proper commit messages and the fact that github doesn't seem to steer users toward good habits. Given the size of his projects and the number of contributors, I find it reasonable to demand well documented and informative logs. As a developer, you have to be considerate of the time of people who have to decipher your work and intent. Obviously, it'd be better if the UI was prompting you to do so, so you don't have to suffer the wrath of the "opinionated" project owner ;-)

And with distributed development, there needs to be accountability, arguably a greater standard of it. I, too, would rather err on the side of a conservative approach, especially since it pertains to the Linux kernel.

To add to dclowd9901's point -- for a full understanding of what can happen to a giant project if accountability is not strictly kept and logged, see the SCO case (and its related firestorm). Linus and many others went through a lot of crap and are understandably a bit strict about preventing that from happening again.

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?

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.

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.

Miguel de Icaza isn't exactly known for being nice, but even he defers to civility. Belive it or nor, respecting other people, even if they don't have your gigantic brains or knowledge, can go a long way in your social interactions and professional development.
http://tirania.org/blog/archive/2011/Feb-17.html

It's weird because it kinda goes the other way too. Why in the world does GitHub truncate my commit messages now? The 80 char thing is a guideline. If git is willing to dutifully accept longer commit messages and my team and I are willing to read and write them, what's the point of forcing us to click to see them in the Web UI? If a project really wants an 80 char limit, that should be a project prerogative, not forced on everyone.

Mini rant aside, it's a bit confusing. Because as Linus notes, there's no indication of the 80 char limit when authoring in the Web UI -- you're only penalized for it later. It seems there are competing sets of best practices.

Okay, have you been following closely Linus or Crockford? I know I haven't, which is why I always start from the position of "I don't have the full context."

My initial assumption is: Linus/Crockford/whoever-else-is-coming-across-as-a-cranky-old-person has seen whatever-he-is-berating or something very similar before, not just once but ridiculously often. That makes the reaction quite understandable and justified.

Plus, let's face it, we all want to be free to react like that when it's deserved ;)

You know....you may be right...about 'we all want to be free to react like that when it's deserved'.

I guess it was off-putting to me because of the ephemeral effects of him being who he is. Anybody could (and probably would) complain about the way Github has implemented various features - but they wouldn't get the attention that he has gotten. Maybe that's why I perceive it as him being 'cranky'.

So maybe my criticism was unfair because I wouldn't have criticized DHH for doing the same thing - or who knows, maybe I would.

> 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 think it's a response to the relatively recent over-abundance of attention and coverage given to wheel re-invention and uninformed opinion. I personally tie it to a particular subset of startup culture that relies heavily on convincing young developers to serve as grist for the startup mill by appealing to their ego.

I think you misunderstood what Linus is complaining about. He's not saying that everyone should format pull requests to his liking. He is saying that pull requests for things going into the kernel have to follow the formatting rules that project uses.

This is not a cranky old man thing. This is a basic multiprogrammer project collaboration courtesy thing, similar to the reason that, say, if a project uses camel case variable names and one statement per line, you shouldn't submit code using foo_bar naming and putting as many statements as you can on a line.

He's always been like that. Really that was the status quo in open source 10-15+ years ago. People were abrasive, efficiency oriented and most of the communities didn't have very many soft edges. Just off the top of my head I'm thinking of Theo de Raadt, Miguel de Icaza, Richard Stallman - hell if you were a nice guy you didn't make it on usenet back then.

In the last 5 or 10 years there has been a strong shift towards emphasizing civility and positivity even if it gets in the way of getting things right or expediency. I can certainly see the appeal in it, after all lots more people are drawn to programming now with a wider variety of personalities and motivations. I won't say it doesn't make sense to be more inclusive, but it certainly didn't used to be the norm.

Rails core homes on github right? What is it that they do when they don't like a pull request? Write a long blog post about how stupid people like you are a net drag on the open source world and keep awesome people like us from helping you even more and and rss it out to everyone.

I don't have a lot of first-hand context for Matz's behavior, not being a Ruby developer, but it's entirely possible, even likely, that in the context of Japanese culture, Matz's niceness would not be seen as especially remarkable. Pitting one person's "niceness" against another when they are products of vastly different cultures is questionable at best.

To most westerners, the average Japanese person is extremely polite, if not bordering on the absurd, while to most Japanese, the average westerner is, to say the least, unrefined, and Torvalds is probably downright horrifying.

Such things must be taken in their cultural context, or you can't really understand people's behavior at all.

I totally agree. The past few links on HN to comments by Tovald have been full of inflammatory, juvenile language. I'm sure the guy is intelligent and certainly deserves a place in CS hall-of-fame, but I think the way he carries himself in these forums has tarnished his reputation.

Note Torvalds is incredibly polite and articulate when speaking to the public or press. However in technical fora he carries an old-school 1992 usenet-style flamethrower. Its just the way most of those old *nix guys interact.

Linus may be an ass at times but he has earned that right, and is one of the few people from whom an abrasive attitude is tolerated. I would strongly caution you that most people do not find that sort of attitude acceptable.

And yes, this is a throwaway account. It might be worth considering why I created it to respond to you, just based on your post above.

Wheras mine isn't a throwaway and I never use them, for reasons I shall endeavour to make clear.

My opinion is my opinion, and you're welcome to hold a different one, but I'll damn well stand behind holding mine and explain the reasons why I do as myself, with my reputation and my ability and everything I've ever said attached to it, including the stupid, horrible mistakes (of which this post may later seem to me to be one :). Because the fact that I do my best to make less such mistakes every year speaks for me as well.

You are absolutely right that it is worth considering why you created an anonymous coward account, as slashdot calls them, rather than speaking your opinions as yourself - no matter how strongly you disagree with me I respect your right to do so even if I have no respect at all for your arguments or position. But now I have no way to know you, and no way to respond to a human being rather than a (to me) meaningless transient front so I don't really feel like I can draw any useful conclusions from such consideration.

I don't know why you'd want that.

If you want to disagree with me, disagree with me as -you-, so I know who I'm debating with and can frame a constructive reply.

Perhaps the fact that I would rather disagree honestly with another human being, and that you would ... I don't know what you'd rather ... is the point. Perhaps it isn't. But now I can't know.

Arguing for "most people" holds no weight with me when I'm unable to even confirm that you're a person. Maybe I'm too web 1.0 or something. If so, sorry.

Please do, however, consider responding to me authentically; I'm always willing to debate whether I'm right or not, but I've always been rather fonder of debating people than will-o-the-wisps.

Maybe that's just me. Deciding that is left as an exercise to the reader :)

Of course such options exist. Honest and authentic communication is a crucial tool to avoid disagreement descending into flamewars.

Linus' original post attracted a message from an original developer saying "yeah, I hate that too, we'll try and get round to fixing it". That suggests that his choice of option was really rather constructive, peanut gallery interruptions to the useful parts aside.

I disagree with Linus's digression to insult a member of the peanut gallery, no matter how useless and unnecessary said member's interjection. In my mind, a "No, that's wrong." is sufficient if it even merits comment.

Funnily enough...DHH's talk is EXACTLY the first thing that came to mind when I saw Torvald's comment.

Who cares if Torvalds has 'more' technical chops than DHH...DHH might be more abrasive, but it is a good abrasive. He is always pushing the community forward and encouraging Rails developers to be a little better. He is not afraid to embrace new technologies and give credit where its due.

I have never once bashed his contributions to the community and OSS. Just like I would never do the same for the creators of Java, C, PHP, all of which I don't use and have no interest in. But there is significant value in all of them and we are all better off for their existence.

My point was, more often than not....you hear the creators of these 'foundational' contributions complaining about new things (either new approaches which were different than theirs, or they shit on new languages because those languages don't have some purist function that theirs does or doesn't achieve the same low-level execution speed that theirs does).

DHH can be a dick, but I have never seen him shit on someone for trying something new (even within the Ruby & Rails core). That being said, I am not saying he doesn't disagree with the approach that people take....but there is a difference between shitting on someone/something and disagreeing with it.

What Linus did here was shit all over Github's implementation of the pull request - because it is different than his implementation would have been.

Why do you conclude that Linus is shitting over Github's pull requests simply because they are different from what he would have done? What possible reason do you have for jumping to such a superficial conclusion?

I'm not going to speculate, but it's clear you are talking out your ass.

Linus has spend the last 20+ years building one of the most important pieces of software in existence. Not only that, but he created git, without which the Github guys, DHH, and everyone else would be using fucking Subversion. The process that he follows for kernel development does not exist out of vanity, it serves an actual proven purpose. Linus' care and attention to detail are a big part of why you can rely on the stability of Linux over time. For you to come in here spouting off some nonsense about why he does this or why he does that without clue #1 as to the real reasons, and then to pay homage to the guys who are "trying something new" all the time standing on the shoulders of said giants, well, it's a slap in the face. Respect is due my friend.

I think you misunderstood that a lot of times so called "new things" are already thought about by those creators. But they may thought about cases that those new things are not a good solutions to problems and they decide to implement them in different way. In Crockford's case, it is the ';' at the end. And he wants to enforce it for clarity. And in Torvalds' case he wants accountability. I don't think they did not consider those new ideas when they start designing json/git, but they choose ways that facilitate programmers to create better/clearer/more accountable ways to solve problems.

I think for all software engineers who are old enough, we all know writing software is a social activity and sometime it is better to make projects manageable.

I think any one who creates technologies has to understand that design decision is an "Opinion".

> Java, C, PHP, all of which I don't use and have no interest in. But there is significant value in all of them and we are all better off for their existence.

I doubt we are better off for PHP's existence (only mentioning the oxymoron "PHP security" should be enough to make this point), many would argue the same for Java (unless you are a consultant or book publisher), and some have argued the same for C.

And just because something is new doesn't make it good, in the programming world the number of square wheels built grows every day, and we are in danger of the resulting mountain collapsing and burying us all in a tangle of inscrutable complexity of bad solutions to problems that were solved long ago.

I think it has to do with time and how Linus wants to spend his resources. If you've got small OS project you would be happy with every feature or bug fix and probably wouldn't complain about the format of a pull request.

However Linus is heading a huge project and besides that he is famous as well. Everybody wants his time, if only to show an e-mail in which he flamed them to death or to brag they got a commit into the Linux kernel tree.

Crockford is heavily opinionated, and it's reflected in his work. JSLint is like a virtual Crockford, that yells at you for misplacing whitespace, semicolons, using functions with the word 'Sync' in them, bitwise operators, switch statements, and more.

It's hard to fully articulate how wrong this and so many other comments in this thread are.

People have the right to be offended, they however DON'T have the right to not be offended.

Linus is a nice guy, he works well with others and has built some of the most amazing software in the world today. I work on the kernel and other system code on a day to day basis and have participated in threads with Linus before. When you are wrong he tells you so, in a very clear manner that outlines exactly WHY you are wrong.

Sure, he isn't always concise and succinct but that isn't really the point. If he wants to interject a few choice "swear words" to describe how badly you did something that's fine by me. As long has he describes exactly what is wrong and how to fix it.

People need to get a lot less wrapped up in HOW something is said and focus on WHAT is said. The essence of Linus's comments on this pull request can be summarized easily. GitHub's pull/request features are inadequate for kernel goverernance - and as the creator of git and designer of the inbuilt pull-request functionality he thinks this is subjectively retarded.

If you read past any of that and start saying crap like "he could have been more polite" to him then you have obviously missed the point. It's not his (or anyones) job to cater to peoples inability to grow a skin.

Yeah this is exactly what I thought when I read this. There's no excuse to act like a dick, and he totally is in this thread - name calling and being super angry when nobody else is. I'm a little disappointed.

When you reach 30's, 40's, 50's and after you've seen What Works and What Will Not Work happen over and over again, you just might find yourself turning into that cranky old man too. Also, practices which are acceptable with a single coder or a small number, or on a non-mission critical piece of software may not be acceptable in the other kind of situations. A bit like how having no tests is The Right Thing for a one-off task shell script. Whereas not having any tests will be Dangerously Stupid for say rocket control software. When a developer goes from writing a little me-too CRUD web app to then wanting to commit something into the Linux kernel, somewhere in there you cross that kind of threshold.

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.

Don't sweat it; Linus's needs are far different from the rest of us. We're talking about the guy here who made Git just to have a tool that perfectly conformed to his ideal kernel development process. Since his job is basically to be a full-time pull request approver, it makes sense that he would be extremely specific about the format to improve his efficiency.

I doubt your devs number as many as the kernel contributors nor are they working as independently. Perhaps "esoteric specifications" exist for a reason on a massive project which has seen and tried many things in the past 20 years.

If your devs commit bad code its probably pretty easy for you to find them and possibly fire them. If you can't tell who a kernel patch is from or even if it is actually from the person specified it calls into question the security of the kernel.

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.

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.

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.

I think Torvalds position in this issue was correct. But I disagree with the description of him being polite. In one of his comments his quote was like, "You are a moron." That's not polite. Granted, he has a well-established style when he goes into rant mode on a certain issue. And Linux is his baby more than anybody else's. And he almost always takes the right side of any issue. So we should all cut him some slack. But he was not polite.

Again, it's Linux. And the issue was over what/whether/how he should accept commits into torvalds/linux on GitHub. Anybody's free to commit anywhere and fork Linux or make custom builds, distros, etc. But if there's one place he has the absolute right to be a tyrant is over torvalds/linux. The fact that he also designed and bootstrapped git for the whole purpose of doing version control The Right Way, based on his needs for Linux development, is just icing on the cake of that argument. But he was not polite.

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.

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.

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.

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.

This is the first time I've seen his commits, but I do the same thing at work, deliberately. I don't pretend to know his reasons, but I've always had fun with the idea that if there were a super high-level language, it would look similar to a commit message and the corresponding changes would take place. And so I have changes that look like "Optimize the foo() function", etc.

A commit can be seen as a changeset. A changeset can be formatted as a patch.

Projects like Git and Linux take their contributions in as patches that are sent to the projects mailing list. As it is not merged in to the master tree at the time of publishing, it would not make sense to use past tense for describing what it should do, if merged.

Thanks to Git's great history-graph altering functions like rebase and cherry-picking, it would make even less sense. You can always take some commit and apply it to new branches or even repositories.

Whether your commit is historical or not depends on your point of view. Git is distributed. For whose repository is it historical? What if I pull out the commit using git format-patch? Is it still historical now?

See his other rant about Github's handling of single-line commit summaries. When space is at a premium it's a waste to past-tensify all the verbs since it inevitably wastes precious characters in the one-line description.

It drives me nuts that I never know exactly when Github will break my one-line descriptions when there appears to be plenty of room left to display the characters. Like this one from Linus:

I can think of a few reasons for the grammar rules in the commit message...

It is direct, concise, consistent and tends to active voice rather than passive voice. Further, not everyone writing or reading the messages will be a native English speaker. Avoiding past-tense forms just makes it easier.

I am actually not a native English speaker and I always thought that this was hard to understand specifically because English is my first language. But again folks provided enough information for me to understand the reasons for it to be this way.

The HEAD version is a bit different (less clear?), although the intent is more or less the same:

"describe changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour."

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.

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.

He made the same comments when he first moved some projects to GitHub. I believe the kernel.org servers were having issues at the time. In response to these comments, we pushed out several changes nearly immediately, including a completely redesigned Pull Request email notification.

We're always listening for feedback and are working on improving the experience for everyone. It's too bad that useful bits of feedback like this turn into another drama episode though.

Unrelated note: why is there not a news feed for each project? I have a news feed with tons of watched repositories but they all blend together in an unusable mess. I would like to see the history of a project that is not just commits. something like /<user>/<project>/timeline that shows all activity (commits, comments, pull requests, issues, etc....)

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.

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.

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

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.

Google style mono-repository development currently appears to be impossible with Git. If there was a more robust way to manage multiple repositories as a single one, that might work -- subtree and submodule aren't cutting it.

So, you are saying that if you were the maintainer of a project which required a feature such that the Github implementation was inadequate but the official git implementation was OK, you'd use the Github implementation anyway?

It's the enfant terrible style. Signals that you are special, and are willing to back it up, so let's just end the conversation. Nice time saver when you actually are special and can back it up. Terrifically destructive for a "B" surrounded by timid people. A good way to drive a team right over the cliff. I've seen a lot of the latter so I tend to react negatively to it. Plus it's never really "nice".

How is GitHubs "version" inferior? The technology that Linus uses to do pull requests (email) validates even less than a GitHub pull request does. The Linux kernel and git have standards that enforce that e-mail pull requests have to follow certain guidelines, but it's not impossible to apply these guidelines to GitHub.

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.

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.

However, they also have different concerns. It's only natural that the Linux kernel have stricter commit requirements than most of the projects on github. In the wide respect, you want things to be kinda fast, loose, and easy. However, I wouldn't be inclined to run a kernel with fast, loose, and easy standards.

I'm sorry man, I have to disagree with this ... I watched git take off with the launch of github, and I've seen enough people moved to git because of github to tell you that ... sure git would be successful, but without the mindshare of github in the developer community, it would not be as popular as it is now. at. all.

When git was announced, I got it and played around with it for a bit, but I went back to svn, it was only with all the OSS that I cared about working with (rails gems anyone?) or on that I started caring about git in a serious way. I'm only one datapoint though.

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.

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.

I think 80-character lines are less an issue of the availability of horizontal screen space and more about readability. Much the same way proper sentence and paragraph spacing and structure lend to the readability of long articles or other blocks of text, a properly short line length can lend to the readability of commit logs.

I accept and agree with the statement "detailed commit messages and pull requests with context are objectively more useful", but I don't see how GitHub fails in that regard any more than Git does.

You can have horrible commit messages and pull requests using e-mail pull requests. You can have the same with GitHub. Ultimately, the decisions of what sort of quality you demand on pull requests ought to be up to the maintainer, and GitHub is doing the right thing by not enforcing a standard that doesn't work for the majority of people.

I know what you mean, but I don't think the logic follows properly. I think that someone who cares is likely to write better code than if they didn't, but I can assure from my limited experience working with others, caring and passion doesn't make someone a good programmer.

I can't speak for himself, but BSDs, especially NetBSD and OpenBSD are known for their code quality. Quoting from "What is NetBSD?"[1]: "The basic features of NetBSD are: Code quality and correctness ...".

While you are only doing as chj asks, I would point out that NetBSD and OpenBSD have the advantage of being exceedingly compact, simple, have fewer features, fewer contributors, and generally travel at a slower development pace.

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.

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

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.

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.

While many projects / companies work as you say, the linux kernel development model has always been much more like how github does forks. Git was designed to be truly distributed and de-centralized, although many people choose not to use it that way.

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.

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.

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.

Linus rubs people the wrong way all the time. It's just the way he is wired. He enjoys arguments and hyperbole. Once you understand that, you can choose to accept that and interact with him without undue suffering, or not.

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.

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.

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.