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 ;)
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... - removing .patch gives you the normal web based github commit page.
The email address comes from the git commit itself and was added as a result of running "git config user.email" with the email address. Any git repository has the same privacy "problem".
The email address you used to sign up for github (the one optionally kept private by github) and the email address in any commit messages are unrelated.
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.
>Like in Germany people have lots of PC for Jewish people.
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.
You can. Just make sure you say something smart, and everything is fine.
The shitstorm might be, however, a little bigger than usual if you say something stupid. (Günter Grass' poem etc.)
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."
The idea that one text wrapping approach is objectively superior for all purposes is incoherent. By that I mean it is an impossible claim given our most accurate understanding of epistemology.
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.
Please don't insult my English skills. I apologize for failing to copy/paste the last two words; it was an honest mistake, not an intentional misquote. Your rudeness is not appreciated nor warranted.
My point still stands. Calling GitHub a "ghetto of crap commit messages" blames the people who built a system to foster such crap commit messages.
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.
I apologize if you thought I was being rude. I was actually trying to not insult you, in case you were ESL. And I only went in that direction because I didn't want to believe you were trying to quote mine.
[1] https://github.com/torvalds/linux/pull/17#issuecomment-56613...
[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.
> do we let geniuses just do whatever the hell they want
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?
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.
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 :)
Are we? I don't believe you've disagreed with a word I said.
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.
I feel like Tovald should watch DHH's railsconf talk on progress & the 'old' mentality. This feels alarmist, but he like any other githubber gets to choose what gets accepted or rejected.
The fact that you're setting up DHH as a foil to Linus is exactly why the old men are cranky; when it comes to technology, Linus has more qualifications in his pinky than DHH has all put together.
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.
Can't tell when last I have seen these older guys do the same.
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.
Given one of the github guys commented that he had helped develop the first version of pull requests and considered all of his complaints valid and hated the code too.
No, it wasn't petty. It was useful, constructive criticism that the github developers appreciated.
It isn't just you, but I think you are being overly critical :)
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.
So it is basically a matter of respecting his very limited resources.
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.
If Linus wrote a lint for C, I really wonder what it would be like.
Okay, fine. The way he handled this particular issue seems like a dick move. Being one of the godfathers of computer science isn't a license to act like a jerk.
There's no question he's right, but there's nice-right and jerk-right.
This sort of response seems like it only inhibits people's desire to get involved.
> This sort of response seems like it only inhibits people's desire to get involved.
How many projects have had as many people involved as the kernel? Not just software, any project. With people coming and going and working on whatever they want. For 20 years.
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.
They're perfectionists and super attentive to detail. If you look around at some of the hugely successful software companies today I think you'll notice it's a pretty common trait.
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.
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.
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.
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.
He was responding to someone who told him his "shit don't stink". Sort of understandable!
I note that GitHub actually did a blog entry sometime ago about good commit practice, and it seems to be the same as what Torvald's requires. Not sure I'm understanding what th issue is... https://github.com/blog/926-shiny-new-commit-styles
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.
I've always found it useful to start writing my commit messages as if they begain with "When applied, this commit will..." ex: "Resolve #459." "Fix the PDF rendering issue on older clients." "Revert commit 1234567."
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.
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.
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.
I like the "super high-level language" perspective. I imagine commit history like a (journaling file system's) journal, whose commands can be undone and replayed.
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.
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.
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.
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.
> 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.
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...
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.
> 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.
Probably true, but when you've changed the technology world twice before age 40 people tend to cut you some additional slack.
> Git is a notoriously user-hostile piece of software
Then you probably didn't use any SCCS before git. Because CVS is even uglier, Bitkeeper is the reason Linus wrote git and every other I tried was more "user-hostile" than git.
> pretty much the only thing it has going for it on the usability front is Github.
You sound like a Visual Basic programmer who just saw C for the first time.
I value no-nonsense style in itself. It's efficient and direct to the point. If you don't have something to back it up, then it is no no-nonsense whatsoever. It'd be just plain nonsense.
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.
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>
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.
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)
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.
Considering that GitHub is probably the second best thing about Git after the fact of its existence, I think that both sides of the table have something valid to say.
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.
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
Linus probably doesn't give a damn about how popular git is. He built it for the workflow that he wants to use. If github doesn't match that workflow, he's not going to use it.
I'm inclined to believe that they agree to disagree.
Linus' use case for a pull request would probably be to much for a popularized and casual use case that is likely typical for GitHub.
And anyway it's Linus' prerogative to dictate his requirements for contributing to his project. The description he gives doesn't make it seem overly difficult (use what's already built-in).
Strange, I knew of git because linux kernel development uses it. I definitely wouldn't go check GitHub if there is no "git" in its domain name.
Github wouldn't exist without Linus' git. I am really surprised they didn't take Linus' advice (reasonable, and no difficulty at all) in the first place.
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.
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.
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.
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.
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.
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.
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"
>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...
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.
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.
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!
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.
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.
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... - removing .patch gives you the normal web based github commit page.