102 participants
How do you feel about merging in things that may include commits downstream that have been pull requested with github? Seems hard to stop that.
Somebody please look at the diff. Thats a simple 3 line code addition. I agree to you @torvalds but you could have excused this time :)
By the way, its quite funny that github is sending instructions to @torvalds on using git.
@torvalds The GitHub commit UI provides a text area for commit messages. This supports new lines and makes it easy to do nicely formatted commit messages :)
@skalnik would be nice if it had an 80-character line to help format things nicely.
Every time another Pull Request fiasco happens on one of Linus's repos it makes me sad, especially because I want someone whose work I greatly respect, to have a good experience on GitHub - instead he gets dozens of troll comments.
An OS kernel very rightfully demands a very disciplined approach to development that is in many ways not compatible with the goals of GitHub, which is to get as many people of all skill levels involved in Free / Open Source Software. We can certainly make improvements though, and I appreciate that Linus has taken some time to detail exactly why he doesn't use PRs, even if it's a bit harsh.
- no sane word-wrap of the long description you type: github commit
messages tend to be (if they have any description at all) one long
unreadable line.
I think this is only because people who are new to Git are using GitHub and not understanding about Git-style committing. Remember, a lot of these newbies are just out of the gate from using SVN for years. I bet a lot of them don't even realize that git commit with the "-m" omitted just opens up COMMIT_EDITMSG in your editor. It isn't even very apparent (to newbies) of the 50-char title rule and 72-char every other line rule with commit messages.
github *could* make it easy to write good commit messages and enforce
the proper "oneliner for shortlogs and gitk, full explanation for full
logs". But github doesn't. Instead, the github "commit on the web"
interface is one single horrible text-entry field with absolutely no
sane way to write a good-looking message.
I have to agree with you there. Commit message viewing on Github sucks and I hope they change it soon.
I always thought of the title of a pull request as the one-liner ...
Newbie question I know, but can someone point me to this "nice pull-request generation module" Linus mentions? My google fu, documentation fu, and command-line-help fu all failed.
@jrep: I believe he's referring to git-request-pull.
I'm not sure I understand why the commit message itself should be hard word-wrapped. Naively, it seems like that should be a display property of the editor used to write the commit message or the tool used to display the commit message.
While I do have great respect for you @torvalds and your work, and it's totally valid for the repository of Linux to have rather rigorous standards, have you considered the possibility there could be a lot of GitHub users who don't really need nor care about any of those "features" you try to portray as objectively superior?
If you add .patch onto this URL you'll get a git-am style patch.
(Github is very silly for not exposing this in the interface, and for not even really mentioning this feature.)
I agree with you on the messages, I wish the text areas were at least monospaced.
Word-wrapping is a property of the text. And the tool you use to
visualize things cannot know. End result: you do word-wrapping at the
only stage where you can do it, namely when writing it. Not when
showing it.
Just curious - why is it that the tool used to visualize things cannot know how to wrap text it displays? And if it is the case, isn't that a problem with the viewer itself, rather than a reason to hard wrap?
Commit messages must be limited to 140 characters, like tweets. Right in git's core.
(See what I did there? What's “pure garbage” for you is just perfect for a lot of people.)
@torvalds Thank you for your rational and good opinion. I appreciate you.
Do you guys not understand that this is Linus' blessed repository and he can accept and reject whomever and whichever request he likes? He has specific and pertinent rules when it comes to merging that he's learned over 20 years of maintaining the Linux kernel. He developed git - in case you forgot, he was the initial developer - with features specifically for gpg signoffs, shortlogs, etc. - things he and other intelligent computer scientists find useful for maintaining repositories.
I've maintained small projects with three developers plus myself and as soon as you become loose with your merging criteria, the entire repository goes to hell. If he wants gpg signoffs, then he'll get gpg signoffs. Try maintaining 20 millions lines of code and merges requests from 2,000 developers, and then you can give Linus advise.
I think @torvalds is a pretty cool guy. eh scolds githubs and doesnt afraid of anything.
While I do have great respect for you @torvalds and your work, and it's totally valid for the repository of Linux to have rather rigorous standards, have you considered the possibility there could be a lot of GitHub users who don't really need nor care about any of those "features" you try to portray as objectively superior?
"GitHub is the best place to share code with friends, co-workers,
classmates, and complete strangers." As long as GH actually, genuinely
cares about making this statement true, they should be providing these
features.
Roman, in the future, you should follow the kernel's guide for
submitting patches. I believe that drivers/bluetooth is covered by the
list at linux-bluetooth@vger.kernel.org and you can submit your patch
to them, with a proper Signed-off-by tag.
FWIW, Reviewed-by: Corbin Simpson MostAwesomeDude@gmail.com, but
there's no way to confirm that since GH is going to hide my email
address and I can't easily sign this message.
(As an example of broken UI, while writing this message, I split my
screen between Firefox and vim, vertically. Linus' messages, being
wrapped, were perfectly readable, but because Github has a massive
minimum width, I had to scroll back and forth in order to read everybody
else's messages.)
@mmorris-gc
Sure, tools can do that, but at what cost?
Mostly messages are read in terminal, not via web interface.
How to distinguish part which should be wrapped from ones that
don't? Add extra tags?
Commit logs are mostly viewed in terminals, which tends to use
monotype fonts.
What about quoting? ">" are clean and indicates
level of quoting.
This ideas are used for years in emails and guess what?
They work!
@mmorris-gc It's open source. Fork it and write a custom viewer for youself. Problem solved.
Amen for the "victim philosophy" comment. If you want to commit or suggest features get ready for feedback. People need to seriously stop crying when others are blunt with them; It's pathetic. (not everyone has time to consider the infinite ways you may interpret something)
I'd have to say I fully agree with @torvalds, I've worked in very strict commit standards, and in very loose standards, and by far my entire experience was a lot better with well formatted standard commit messages. Github does not handle this at all.
Some say that "people don't care", it's mostly because they don't know what they are missing, if it were more convenient to use good standards, everyone would use them.
Sometimes I wonder if the ones who like a massive one-liner as commit message are Windows users...
Sure, tools can do that, but at what cost?
I don't know what the cost is, but I'd be interested to know! That's why I was asking what prevents the tool from doing this rather than requiring that the user handle it.
@factormystic Not sure what this has to do with my question. I was just wondering if there was a reason that the viewer couldn't handle it; I wasn't complaining or asking someone to fix it for me.
Sad that there is no option to disable pull requests via github
@torvalds It is indeed a text area.
On top of this, vim/emacs/$EDITOR does not usually enforce the commit format either. In both cases it's up to the end user to write a well styled commit message.
That being said, I agree it could be better. Perhaps if it was more like the commit form that the GitHub application has.
Since this is seems so important, perhaps git should enforce this style by rejecting any commits with a message that does not adhere to your specification?
why is it that the tool used to visualize things cannot know how to wrap text it displays?
@mmorris-gc That was actually covered by @torvalds above when he said:
Some things should not be word-wrapped. They may be some kind of
quoted text - long compiler error messages, oops reports, whatever.
Not only would it be a tremendous burden for every viewing tool to try and determine which items meet the above definition (and do so correctly), many of the tools we use are generic whereas the formatting rules might depend what domain the material came from, making it literally impossible to display things correctly under all conditions.
@camdez Interesting. Still seems like a problem that could be solved by better tooling, but I appreciate you taking the time to point that out. Thanks!
@jnavia there´s a way to disable pull requests in Github, they call it private repos.
So sad seeing someone who made a great system raging like a child because no one and no system can be like him or how he wants.
@torvalds other than "form" of pull requests what I'm even more worried about is that this new model of contributing code bypasses the former interaction that there is in a mailing list. If the hub of a project is the ML there are better chances that things are discussed before turning into code that will be refused. Even when the approach starts with a patch, it gets publicly discussed by interested parties, and a long term trace remains in the ML archive. It's a pretty different way of doing this, that was used to build a lot of code with success, and one that works better for a project where patches and new ideas are scrutinized in depth before being accepted.
@torvalds I would like to take this oppurtunity to say thanks for Linux and git. For without both of those this great coding community wouldn't have had a chance.
I'd also like to point out something else GitHub does do really well. This. What we are doing right now. Socially coding in an open environment. Talking about things, being connected. Hell when I was growing up I never thought I'd get a chance to say something that Linus effing Torvalds would get to read and possibly comment on, and now here I am, able to put in my two cents (in a flood of thousands of pennies). So thankyou. Thankyou Linus for making git and Linux, and thankyou GitHub for making coding social.
@leobalter No : disabling pull requests does not mean making a repo private. As many other opensource projects, the linux kernel has its own workflow, so why not follow it? At GH, they are aware of it, they even mention in the progit book.
And before "raging like a child" about his comments, read them again: he just does not care or bother.
My own preferred solution would be if GitHub kept to one commit message box but live previewed how it would appear below with 72 character wrap. Then you could see clearly what the short and long messages would look and could adjust accordingly (this is done in Stack Overflow and is very helpful).
The last issue is that monospace is required to view / wrap correctly. A natural way to handle this is to use the markdown four space indent syntax, but since this could get annoying it might be better to have an input type pulldown (text vs markdown) in the same way editing GitHub wikis allows.
@jnavila github has its pull requests as they are. Maybe no one follow "high standards" Linus but it´s great in my workflow.
My point is: raging like a child is unnecessary. Turn of pull requests notifications and don´t answer.
If this github pull requests mess your day off, start thinking about using other code hosting.
The community doesn´t need to be blamed for not being such highness standards followers, we just need people collaborating, because it´s open and many visions are still great on any project.
I'm not sure why this topic is about pull requests not the feature of editing files online. Most of the people create pull requests out of branches prepared locally, I've prepared tons of pull requests and I've used online editor only once.
@leobalter, you're missing the point, this isn't about downplaying the current workings of github, it's about suggesting better workings for github. Just because you are fine with having pull requests on doesn't mean there shouldn't be an option to turn them off.
@leobalter He's not blaming 'the community', he's pointing out what he thinks needs improving in GH. Raging like a child? If you don't like his 'childish' opinion (read: high standards), don't open a pull request. I'm quite happy to see the conversation that's followed as a result.
I work at a financial institution where a single line code change can be backed with 50 page specs, 200 lines of test code, 2 weeks of testing, etc. Asking for a decent commit message on your own repo isn't that big of a deal.
@camdez Are we talking about only the situation where some text shouldn't be word wrapped though? Are there other wrapping related formatting concerns with plain text?
I agree, especially the identify verification via confirmed email addresses, digital signatures, or a mix.
@torvalds I think you missed my point. I'm not just talking about people using Github to host. You don't merge everything in Linux yourself, you defer 90% of that through a trust hierarchy (as you eloquently described in your Google talk about Git). Unless you somehow enforce that everybody under you also refuses Github pull requests, your logs could still get soiled.
@antirez How is the discussion of a pull request on GitHub different than the discussion of a patch on a mailing list? Is it that you end up with two different places to discuss things - mailing list for things without patches, GitHub for things with patches? Or is it that subscribing to see pull requests for a project is not as elegant as subscribing to a mailing list?
My company has had quite a bit of success having in depth discussions about both experimental and more straightforward patches on pull requests, and treating them as the long term trace of discussion, much like you're suggesting - what would we gain from using a mailing list instead?
@johnmetta Oh, you must be new to the internet, or to @torvalds rants :P
Linus, I love your rants and your code. @torvalds.
I like how @torvalds rants on a high niveau ;)
nice read, and I have to agree (tho the "moron" comment really wasn't necessary)
Did you see about adding .patch to the end of the pull request URL like so: https://github.com/torvalds/linux/pull/17.patch
I'm no git-expert, but doesn't that have all the information?
Not sure what all this fuss is about. @Torvalds points out that due to definite weaknesses in GitHub's UI he won't accept pull requests, and the world starts whaling on him. It's simple: if you want him to pull your changes in, don't use GitHub to generate the request. This would probably be easier than trying to change his mind.
If the rules for writing good commit messages are that mechanistic, then @skalnik made a good suggestion: provide a way for maintainers to specify a validation function on commit messages. Could be a nice feature.
Why is Linus word wrapping his comments in this thread? Looks silly.
I fully agree with @torvalds. GitHub is a UI that replaces an important feature with inferior version, have no excuses.
I think github devs should really take @torvalds remarks seriously for two main reasons.
Git was built for kernel and designed by @torvalds, so even if it might not seem important for some new people to git and github, there is a reason for git commit messages and pull request to respect some rules which might not be evident, and Github has a great responsability in teaching these rules to new comers.
Second, Gh might be the best tool/platform to start using Git, so with all the possibilities given by a modern web service like Github and how easily UI can be tweaked, it seems like a waste not to build on top of best practices. Seriously how hard is it to make a text field validator for respecting git commit messages ?
I just want to get on the record as one of the original pull request developers that we've been aware of these issues for a long time and certainly take them seriously. There are a number of problems we need to address that would make maintainers's lives a lot easier.
There's no question Linus's feedback is warranted. I could add considerably to his critique, even. (Mail headers anyone?) Nobody hates these issues more than we do.
@torvalds is very clear on what Linux needs if the contributors wants to send him pull requests. I think Github should just look into this and fix the problems.
Github was made for 'easy & fast' code management, perhaps this is not the right tool for this job.
I don't agree that there should be rigid pull request standards in place, it works fine for 99% of the smaller projects that are hosted here.
The ticketing system on other hand.. is another story.
(not everyone has time to consider the infinite ways you may interpret something)
I can think of only one way to interpret Linus telling someone "You're a moron." There is no subtle nuance there.
Sure is my way or the highway in here.
My comments keep getting deleted lol
I hate that whole "victim philosophy". The truth shouldn't be sugarcoated.
By truth Linus is of course referring to his own opinion.
No doubt his manner is abrupt. Possibly curt. Probably rude. It's fairly obvious @torvalds doesn't "suffer fools gladly". For all I know, this may be a necessary strategy, though it's certainly not one I would find productive. But luckily for him, I'm not him. I do know prominent open sourcerers who are, I wouldn't say harassed, but certainly imposed upon mercilessly. The "nice guys" end up conscientiously dealing with at least some of the traffic, which takes up time that could be spent working or with their families and friends.
But the most important points have almost been lost in the noise: a) @torvalds made explicit complaints about the github pull request, with cogent reasons why it was unsatisfactory; b) Github responded (nice to know they watch their logs) explaining that they are aware of the shortcomings, and others not mentioned, and are working towards fixing it.
It's pointless to argue and bicker
Linus doesn't respond to a clicker
So just make a note
He's a crabby old goat
And then we'll all get along quicker
The Miss Manners conversation can now continue :)
The content you are editing has changed. Reload the page and try again.
Why is it possible to commit using the web interface anyway? I agree that it's difficult to write decent commit messages using the web interface, but it's even more difficult to write decent changes using the web interface.
People often either don't have knowledge of the organization of the project, or they are half asleep when writing the changes using the web interface.
Anyway, this discussion about wraps is getting me hungry.
I started reading this thread with no opinion. Then I realised I started reading
@torvalds nice newspaper column like posts with ease and skipping
non wrapped texts, and said "uhm, that's the point!"
So now I do have an opinion, all comments should be line-wrapped.
Thank's for the lesson :)
@torvalds You have a lot more patience than I have. I rarely even log in to github (website); once in a while I'll go in and just blindly delete all the pending pull requests unless I recognise the name of the person.
I've long had a policy of "no pull requests, no issues, no comments on code via github; everything on email only" and if people don't know that it's their problem.
[edited to change "tolerance" to "patience" in first line]
@sitaramc Maybe the solution is for Github to convert actions that were created with the web interface into an email friendly format and send it out like it does for comments. That way all parties are satisfied regardless of which interface they prefer (web or terminal).
In defence of Linus's attitude here:
There is one thing you need to bear in mind about the Linux kernel. It is an operating system kernel -- the most fundamental, critical software component of your entire computer. If it goes wrong, everything goes wrong. On top of that, it is probably the most widely deployed OS kernel in the world, being used from everything from transport to logistics to medicine to the military to aerospace. Many of these are applications where people could be killed if things went wrong.
A system of that nature requires much more care and attention to detail than your average vim setup or pet weekend IOC container. If that extends to issues as seemingly trivial (to some people) as word wrapping on check-in comments, then so be it. And if the lead developer of a project such as that does get sharp with people, it's not unfriendliness and political incorrectness, but simply due care and attention with regards to the bigger picture and the stakes being so much higher.
@AlekseyKorzun, "easy and fast" development is based upon code that's easy to manage. Loose pull requests really hurts efficiency in code management, no matter for big project or small project. A rigid pull request standard would make the development easier and faster, especially for projects involving multiple contributors:).
@JonDum sounds like a nice idea but consider this sequence. I get an email from the website. I reply to it, cc-ing someone outside github. The original requestor (who is interacting only via github's web interface) sees my reply and replies to that. At this point I believe the guy I added in my CC does not get cc-d and is out of the loop.
At least that's my recollection of this; maybe they fixed it...
It's not hard to fix; qa.debian.org does it ok I think. So does bugzilla, IIRC and probably many other such systems.
I think that if @torvalds does not like github, he can move "his" project to another site. I like github web interface. We are on 2012, not on 1980. Probably Linus use a 80-char green-on-black display. The real people mostly not.
Furtherhand, @torvalds cannot say "you are a moron" while his minions clap. It is hateful.
@robermorales He explained already why he hosted "his" project here in a very sensible manner. Read comments.
There are quite a lot advantages using the 80 chars convention even in 2012.
He is the only reason why we at least have a sensible "80-char green-on-black display", respect him for that.
@robermorales move "his" project?
You're here because you use git right.. who specifically do you think wrote git?
Linus wrote: "For some reason, github has attracted people who have zero
taste, don't care about commit logs, and can't be bothered."
It seems like github is written using C++ :-))
I'm fascinated by how many comments say things along the lines of "why not enforce the commit message formatting" or "github should add validation to the commit message tool". The point is that you can't validate or enforce good formatting, since only the author knows which parts of the text should be wrapped nicely and which parts shouldn't.
On a side note, doing a good text editor in a web browser that looks nice and works well is very very challenging.
@yobert no, you can't (or should) not enforce the commit message formatting,
but you sure could validate it. Look at how vim does this with colors when you
use it as your commit editor.
@n3storm @SkaveRat : I don't share your opinion about auto-wrapped email.
First, I feel sick reading those auto-wrapped comments in this thread because I always make a "stop breath" after each end of line. It's not natural, especially with non-monospace font. Imagine reading a book where text is not justified and text width is 3/4 of the page. That'd be weird.
It's not your responsibility to format the text displayed in a web page. If your feel uncomfortable with reading all other comments, maybe the designers at GitHub should change the font-size or the .discussion-timeline div width. The only reason is if you read that thread on your terminal... which leads to my second point.
My second point is : I don't read my emails on a terminal!, like most of people. I hate when somebody send me (wrapped) text-only email that are very hard to read on a smartphone (need to scroll horizontally), and often looks weird on the web interface, like @fogleman noticed it here.
That could be compared to a width-fixed content like PDF which is not adaptable (/responsive) for all supports, whereas HTML is.
On the other hand, most people use a terminal or a monospaced text editor/IDE to code and use git. That's why I totally agree on wrapping message commits, but not in emails or in comments.
So my opinion is: don't use a web UI as your main tools to make commits -- most people work locally anyway, this is just here to provide a quick (and crappy, ok) solution when you don't have your usual working environment. But Github pull requests are really awesome and are much more user-friendly than emails.
Wait a minute, I'm going to invite Tanenbaum to this conversation.
Look here for a good example of a recent valid pull request:
To be fair, pull requests on GitHub are not that different to that. Pull requests (and issues, which are very related) here are a replacement for mailing lists. It’s where the discussion is going on. All the data you mention is available in a pull request as well, just not that visible. Instead you have to look at the commits appended to the request, or the diff view that’s next to the discussion tab.
Obviously that’s not how you do things. You are an email person, using mailing lists as the main (if not only) way to discuss and propose changes to your projects. And I think that is perfectly fine, especially looking at how well it works with your projects.
But I don’t think that makes pull requests on GitHub inferior. They are different, yes, they require a different workflow, but that workflow works extremely well for many projects, especially those that are not using other means for communication (like mailing lists).
A bad style for commit messages or reasoning of commits and pull request does not come automatically with pull requests on GitHub, the same way as a good style does not come automatically with mailing lists. I’ve seen many perfectly described commits in a well-reasoned pull requests on GitHub, and I’ve also seen as many bad requests in mailing lists. You can do both good and bad things with either (or any) system, and I personally think GitHub offers a great system for projects that are not as busy as the kernel or Git itself.
Github should supply a mechanism for disabling pull requests from the Admin interface, so these conversations aren't required and people like @torvalds can make his own decisions on how he wants to receive commits. At the moment, pull request capabilities are always on so one needs to constantly close them, explain to people why, rinse & repeat.
@MattKetmo, just to give you a clue, ever wondered why you prefer reading books
in a tablet or pad and not in a 29'' screen?
Even in year 2030, human eyes will have the same comfortable eye scanning and
skimming range, proportionally to font size, of course.
Just add a feature to disable pull requests on a per-repo basis, GitHub. Since it's an option, it doesn't need a majority of users to want it, to justify adding it.
It's also a good first step to take in fixing pull requests.
@n3storm Sure, I agree with you about having a "comfortable eye scanning and skimming range".
I'm just saying breaking lines at 80 chars for that kind of content doesn't solve the problem (except in a terminal). Text should be displayed at fullwidth in a pad, and in a column of "xxx" px max in a 24" or 42" screen. Line breaks won't be the same depending on the support, so manually breaking lines can make reading harder.
I can't believe this whole discussion has gone on with no mention of format=flowed, probably the best thing Apple ever did. Not that it really applies to the question of how git commit messages should be formatted (or does it?), but you shouldn't be commenting on formatting of plain text emails unless you've read that rfc.
I love it that you can easily know just by
looking at word wraps of the comment
whether a person is supporting Linus or not
For future reference, here are the HN discussions on this topic:
http://news.ycombinator.com/item?id=3960876
http://news.ycombinator.com/item?id=3964252
@fisherwebdev
I know! It's 1940s all over again.
@fisherwebdev Ad hominems will take you nowhere. I don't know how to tell you this, though, because you seem easily disappointed, but he's not German either.
@fisherwebdev ???
@fisherwebdev he's neither German nor a moron. He's empowered with other tastes and made development easier for all of us (with linux and git).
Curious situation where I find myself installing linux while laughing at the absurdity of the Linux core team.
We're supposed to format our input for your preferred display device? What? Why should data need to be formatted for your terminal when it is viewed in many different environments. Besides, my terminal is more than 80 characters wide. What universe do you live in?
The real culprit is the utter inadequacy of plain-text. This was obvious from my first *nix experiences, when awk couldn't consume stdin because some data contained whitespace, ruining its ability to distinguish columns. Here it shows itself again. Instead of addressing this root problem, we're bikeshedding about number of characters per line.
@JoshCheek (And others, but you're the most recent):
If you have a better idea, I suggest you implement it. Then open source it. Then merge every suggested contribution regardless of it's formatting.
@richo thats like a chinese proverb that reads "Yu Fa Kof Go Doet Be Ta" ? Criticizing something that exists, isn't in the same as reinventing the wheel. And flame bait doesn't add anything to this conversation really.
This is the problem:
Linus:
"My place my rules, I use terminal, do it like that because we do it like that or you are a moron"
Sane person:
"This is the link to the guidelines [url]. Github web interface doesnt help/prohibit enforcing these guidlines. Its ok though, we have a team that can help you do it better next time, just use this mailgroup [group].
plus: Thank you for your contribution however its a 1/5 quality, and we cant utilize it without proper comments.
or: Thank you for your contribution, it has been forwarded to the appropriate team for commenting and quality control
By the way:
I do agree with the fact that he is trying to enforce his rules, thats the most logical and secure in the long run. HOWEVER being all pms about it doesnt encourage the community at all.
@MikeBagos I mostly agree with you. But I think an extra team / mailing list or reviewing code / requests that do not meet current standards that are used by Linux developers would mean as much work or even more than just accepting and reviewing everything they get.
A link, as you suggest, that clearly show "how to do it right" should be enough as answer for everyone smart enough to write code and generate a pull request.
Lesson to learn : The original author will never commit with more than 80 chars in a line ever after.
Linux is the most successful free software because of strict rules. It's not a free-for-all-party. If you were inside Microsoft contributing to Windows, or inside Apple contributing to Darwin or anything, you would probably have to follow some rules as well.
Linus is maintaining the Linux Kernel, he decides the rules to keep it successful and as long as it's working, one can't complain. Work with goals.
@robermorales didn't get your point. But yes, Linus can, you can't. Thanks for engaging this conversation with helpful points.
@JoshCheek @richo I wrote a patch a few months ago that adds line wrapping to Git. It wraps commit messages to the width of your terminal when you read them, and respects convention — lines that begin with whitespace are not wrapped, lines that look like list items are wrapped with hanging indents.
Here’s a squash commit of the changes. Below is an example. The patch was rejected by the Git maintainer, whose objections were similar to what @torvalds brought up in this thread, but I believe that formatting conventions have become consistent enough that it makes sense to move the responsibility for line wrapping to the tools (a good example being comment formatting here on the GitHub website, and on programming websites like Stack Overflow where human-language text is regularly mixed with code).
I believe the point here is that the commit message should be formatted by the author. Like many processing problems this is a write once/read many scenario, it makes sense to spend the extra effort on the single write to display the message exactly as intended.
Noone is forcing you to adhere to this standard in your own repos, the point is that if you want it merged into the mainline linux tree, you need to stick to the upstream convention (as with any project).
It's what they call a "protocol". You are free to ignore it, but then you can't interoperate.
@Sidnicious Nice!
@richo says
"Noone is forcing you to adhere to this standard in your own repos"
But that is not consistent with this post, saying:
"I've told github people about my concerns, they didn't think they
mattered, so I gave up. Feel free to make a bugreport to github."
I agree. It would be awesome if github's web interface provided a sane way to make sure a commit message adhered to the convention.
Still noone is trying to force you to change your workflow.
@Sidnicious It's a shame your patch wasn't accepted. It seems like it'd make the line wrapping problem in the main bodies of commits an entirely moot issue and make commit logs look better across a variety of interfaces.
Also 
;)
Guys, guys, guys. This is really simple just attach your git-push-hash to your remote flow. If your commit messages merge recursively then you're doing it wrong. @torvalds isn't re-fitting your columns just because your soft wraps won't hash with Micro$uck FrontPage or whatever you fucking noobs are doing these days.
Pull yourself together.
For those who do not accept GitHub-delivered contributions for your projects, but who insist on using GitHub for hosting, I would suggest documenting this fact in big letters on the front page of your project as it appears on GitHub, preferably somewhere near the top.
I suspect that the current practice of inviting people to use GitHub with your projects and then chastising them when they do so is unlikely to lead to anything positive.
In the case of Linux specifically, a quick note in the README directing potential contributors to Documentation/SubmittingPatches would probably help. It also looks as if the latter document could use updating to reflect suggested Git workflow.
I like this guy.
@torvalds github will improve, it's a matter of time. The economics here are
that it brings simple 80% functionality to the masses: issues, wikis, pull
requests, privacy. You need 100%. It's the same reason I host my sites on
Wikidot, the github wikis are (still) too simple for my use. I assume it'll work
in a couple of years. In the meantime, that simple 80% lets me bring
non-technical people into the process, which is a real benefit.
I don't mind arguing. It's one of my favorite hobbies, in fact.
That's a bit redundant by this point.
@BilgeXA the problem here in the github community is that there are also people that don't argue, but like you write comments that are not going to be useful in any way. There is this idea that trolling is cool. This is the triumph of mediocrity, actually.
@Sidnicious I would imagine it was rejected because there is a large minority of cases where you don't want a line larger than 72 columns to be wrapped--it's often more important to see how the text was originally formatted, and a set of error messages starts to look terrible when they're a bit too long for the terminal. Often, the first 72 characters are enough to get the meaningful bit of the error message (especially when you have several related in a row); when it's not enough, the reader can choose to resize his terminal, swap to the next set of columns, etc.
Since it's hard to automatically word wrap prose but not code/error messages/program output/etc., and the functionality is not universal, it makes sense to place the onus on the writer to format his text in a way that will be easily readable for a large set of readers. As with writing in general, the writer cares more about having his output read than the reader cares about reading it; spelling rules and grammar conventions exist to provide a low barrier for the reader to quickly understand the writer, not just so teachers can slap wrists over syntax. Likewise, conventions about formatting and what data to include are provided so that the reader can parse your output quickly and move on to one of the hundreds of other similar pieces he needs to address.
80 characters has remained a safe convention not because it's the widest anyone thinks a terminal should be, but because it's a safe minimum that everyone can expect, and which tends to work well for visually scanning, at least at current font sizes. The width has the added benefit of allowing developers to have multiple windows visible on their fancy modern screens with the knowledge that there is an accepted width to which they can shrink their terminal and still get predicted behavior out of 90% of the data they can read. I currently have several dozen windows open, and almost a dozen tiled visibly on my screen; I'm very happy that I've been able to keep my terminal at the same width for several days and meet pretty much all of my needs.
At any rate, I haven't seen anywhere that @torvalds thinks GitHub should require every user to follow his desired convention--he simply thinks the tools should be reworked so that they enable and encourage developers to do so. Imply that certain pieces of information and formatting rules are desired, and many new users would fall into the habit. Several people have mentioned a markup that would allow GitHub to know what to wrap and what not to; this would allow a maintainer to set conventions for their individual repo, and would produce better output with less effort from the writer. While this would do less to educate new git users about useful conventions, it would still lead to better output.
At the end of the day, it's the writer's job to ease the reader's job, and it's the tool's job to ease the writer's job. An optional/default setting in the tool and perhaps viewers that makes it easier for people to follow convention without worry (heck, I didn't know that the git convention was 72 as opposed to the traditional 80 until I read this thread) would go a long way.
What the f*ck is the problem with just trying to get github to improve?
Nothing. I agree entirely that they need improvement in this area, and some others.
However, I don't believe that being unpleasant or unhelpful to first-time Linux contributors will get GitHub to improve. (Unless we're talking about contributors who are also employees of GitHub, which I don't believe we are, right?)
When I see a project on GitHub, my expectation is that the project maintainers would like me to use GitHub for any contributions. If that's not the case, I would expect them to at least say so on the project page, so as to avoid wasting my time.
In fact, it might be even better to leave an open blank pull request on GitHub that's just a placeholder saying "This project does not accept pull requests via GitHub", with a note saying where to find the documented submission procedure. That way anyone who wanders into the pull requests area will find out they're in the wrong place.
Just ignore pull requests (leave them open). It'll rapidly teach
people to use other methods. You're not using the issue tracker
anyhow, are you.
And you should point people to the kernel contribution process right
up front in the README; this should explain how to make pull requests
and why you don't use or accept github pull requests.
@lpar, @hintjens: I disagree, I don't think adding GitHub-specific instructions to the Linux README is a good idea for two reasons:
- Not everyone uses GitHub to contribute code to the kernel.
- The Linux kernel source is hosted in multiples places, GitHub is just one of them.
Therefore adding GitHub-specific instructions to the README wouldn't make sense for those cases when the kernel source is hosted somewhere else.
Why not fix the real problem instead? Adding GitHub-specific instructions to the README is a band-aid solution to a problem that can be fixed now.
FIX GITHUB, SOLVE THE REAL PROBLEM
Or live through me cursing at you and calling you names.
That certainly seems to be a challenge for some people. :) I'm sure Linus has been called a moron for a lot of his ideas (especially before he was famous / respected) but he shipped working code. Maybe that changed their tune, maybe it didn't. I doubt he cares all that much either way.
I think if you aren't called a moron for at least some of your ideas you aren't trying hard enough. Get over it and ship some code.
Frankly, I took Github for another example of opinionated software like so many other Rails/Mac examples (Basecamp, Heroku just to name two other services). I think those developers have very strong views about their logic and are not likely to change it.
You are good to go as long as you follow along their logic, if not there's really not much love for you - instead they will usually tell you how to understand it and why they think it's brilliant, straight forward and all the other subjective attributes.
I'm using Github but I don't expect them to change for me.
(In this specific case however it seems Github developers actually want to change things)
So, really, the simplest thing would be for github to allow you to disable pull requests on a repo.
There's more to private repos than pull requests but I also suspect that not allowing to disable pull requests might very well be a marketing decision knowing that other options are given ...
turl
referenced
this pull request
from a commit
in allwinner-dev-team/linux-allwinner
|
77650df
|
@torvalds Are these higher standards documented anywhere?, since —I'd bet— people in general feel for github for the social value of pull-requests/forking (don't look at me, I prefer bitbucket/rhodecode and mercurial [yeah, sorry])... seeing the linux kernel in github might cause them having a false expectation of this space and it would be best to rather channel their contributions through the appropriate channels/filters.
Why not create a single wiki page with a link to that (or verbatim copy of them) with a brief explanation of the purpose of this space?. Oh, I don't know, something along the lines of:
Dear morons,
This github repository is for you minions to backup the kernel, If you would like to contribute like a non-moron,
please read our commit guidelines over here.With love,
Linus
I advocate for not sugar-coating anything as well (valuable time is generally lost in hypocrisy), and even when I enjoy reading drama in communities (open-source or otherwise), I don't think conflict is something good for any community, even if it is an extended community that doesn't matter that much (who needs 5k+ watchers & ~.8k forkers).
This general confusion might lead to conflict in the future and can be avoided easily.
My 2 mexican cents
you could write a custom hook which triggered to the pull_request event and automatically closes (Update a pull request, setting the stat to closed) the incoming pr with a comment explaining the proper way for sending patches.
http://developer.github.com/v3/repos/hooks/
http://developer.github.com/v3/pulls/comments/
Hey @holdenweb I like your poem! :)
take it easy
Oh awesome, we're reviving this? >.<
This shits being picked up again because it was mentioned in some article the other day on wired or gizmodo or some shit like that.
FUCK YOU NVIDIA!
Yes, GitHub should propose a validator or an assistant to the editor in order to write good commit logs or pull requests.
That is why high level web interfaces can be so helpfull for some young people who need assistance to learn how to make good commits (those young people just use web interfaces every day and will do it more and more through their cloudy platforms).
PS: I'm not that young and I love my vim... ;)
Hm... is there any way we can close threads like this ?
@dysoco Nope, but you can disable notifications (see the link down there ↓) ... which I'm doing right now :)
Most of the recent traffic on this bug is from people putting "#17" in their commit message. GitHub really needs to fix this too -- how many times is this bug is going to be "referenced" over the life of the kernel?
Interestingly, most of the referenced commits have awesome commit messages. And they'd be near impossible to write using github's ui.
vineetgarc
referenced
this pull request
from a commit
in foss-for-synopsys-dwc-arc-processors/linux
|
|
vineetgarc |
No description provided.