Am I the only one that thought this was someone asking Linus Torvalds to write better commit messages?
Perhaps it would be more clear if the quote was in quotes.
Linus: please write good git commit messages
11–20 of 58 posts
Re: Linus: please write good git commit messages
#12I'm curious about this:
please do proper word-wrap and keep columns shorter than about 74 characters or so
How come word-wrapping is left as a task for humans here? Is there a technical/stylistic/cultural reason why lines can't be wrapped automatically to any desired width by the log presentation layer?
Re: Linus: please write good git commit messages
#13Re: Linus: please write good git commit messages
#14I'm curious about this: please do proper word-wrap and keep columns shorter than about 74 characters or so How come word-wrapping is left as a task for humans here? Is there a technical/stylistic/cultural reason why lines can't be wrapped automatically to any desired width by the log presentation layer?
git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery.
The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.
Re: Linus: please write good git commit messages
#15I'm curious about this: please do proper word-wrap and keep columns shorter than about 74 characters or so How come word-wrapping is left as a task for humans here? Is there a technical/stylistic/cultural reason why lines can't be wrapped automatically to any desired width by the log presentation layer?
git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery. The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.
Making semantic line breaks (such as for bullets) is understandable, but it still feels wrong that we’re otherwise doing the job of `fold`. I started breaking lines in commit messages because it’s convention, but I still believe this is a tooling issue.
This shell script wraps wide commit messages to the width of your console.
GIT_PAGER="fold -s -w`stty size | awk '{print $2}'` | less" git log $@Re: Linus: please write good git commit messages
#16Earlier quoted context omitted.
Ah, but what if we encouraged programmers to write better commit messages? What if we splashed on a bit of gamification to raise everyone's level of awareness? Maybe a badge on your profile page...?
How would you objectively determine the usefulness of a commit message, though? While it might contain all the necessary parts, there is no way to determine if the sum of the parts adds up to a useful whole. Also, badges are done to death. Everyone's got badges these days - so much so they're like ads. Personally, I've developed a blind spot to most of them.
Objectivity is irrelevant and impossible in this context of raising awareness and fun. If the mechanism was something as simple as an upvote next to the commit message, you would let the community define usefulness of the commit message.
Re: Linus: please write good git commit messages
#17I'm curious about this: please do proper word-wrap and keep columns shorter than about 74 characters or so How come word-wrapping is left as a task for humans here? Is there a technical/stylistic/cultural reason why lines can't be wrapped automatically to any desired width by the log presentation layer?
git-log and friends indent the commit message by four spaces on the left, so wrapping at ~72 chars gives it symmetry on 80 column terminals. By wrapping it yourself, you decide where line breaks should be, not the presentation machinery. The optimal human-readable line length is something like 66 characters. It's much easier to quickly scan a log message that's 72 characters wide vs. one that is 200 characters wide.
Tangent time!
"The optimal human-readable line length" isn't really something that exists, even if we make lots of assumptions about basic stuff like font size, avg word length, and color contrast.
Here's a quick study on the reading speed and comprehension of character line lengths (cl) between 35 and 95 for reference: http://psychology.wichita.edu/surl/usabilitynews/72/LineLeng...
- most efficient reading (speed/accuracy) at 95cl
- line length does not affect comprehension
But here's the head spinner:
- 60% _preferred_ either 35cl or 95cl
- 100% _least preferred_ 35cl (45%) or 95cl (55%)
Line length is an easy thing to assume everyone perceives the same way, but even given a consistent environment (definitely not a given in this age of increasingly diverse device dimensions) there's a wide range of preferences with little real impact on readability. Unless, of course, your assumptions about readability clash with the user's preferences or reading environment.
Put simply - make your life easy and reduce problems by just letting the user decide.
Re: Linus: please write good git commit messages
#18Not to sound like I'm boasting, but most of my commits are far too atomic to warrant more than a first line. If I need to write several paragraphs about the changes I'm making, it's definitely too large a commit.
Re: Linus: please write good git commit messages
#19At first I thought someone was asking Linus to do this.
But this comes up over and over and people should really start doing it! Especially on large and/or well known projects. This isn't just something that's useful to others but it can help you too! I'm a naturally long-winded person but the point isn't to write an essay, you just have to sum it up on line 1 give some context and details for the commit, then let us know who you are and how to get in touch.
Fortunately I've never had to revert Amy changes in my work (weird, right?) but if and when that day comes I'll be prepared. 99% of my work is done alone but I still write some decent commit messages. Who here remembers the date of your changes? Do you remember the exact state of the project at that time? Even if you remember that "well, the project was in X state Y commits ago" it'll only help you for about 5 commits max then you'll forget.
You need to know what you were doing and so do others. Even if you don't plan on working with others, I'd you're on GitHub with a public repo someone may unexpectedly like your project and want to see what's up with each commit. I recently had a project up on github that I thought was literally only useful for myself. It was a basic brochure style website for someone I made as a favor. Well it turns out someone here on HN wanted to learn to code, got in touch with me privately, then started exploring my github repos nth at guy actually used the stupid website I was building as a way to look at some code, tear it apart, and see how it worked. I was flattered and now I'm glad I write decent commit messages even if I'm only working with myself.
The point is, you'll never know when someone else or even yourself will need to look back at the logs and if the commit message is nothing but a date or something like "fixed the link" then you aren't reverting to a known past state - you're guessing.
I know a lot of Git newbies get scared after pressing return in the command line and nano or whatever built in text editor pops up. I didn't know how to end the commit message the first few times and save it or get back to the "normal" terminal so this may be part of why this happens but not a big part.
In any case, I feel strongly that this is an important thing that's overlooked and I'm glad it was brought up again. Hopefully people do it.
Re: Linus: please write good git commit messages
#20Not to sound like I'm boasting, but most of my commits are far too atomic to warrant more than a first line. If I need to write several paragraphs about the changes I'm making, it's definitely too large a commit.
So, you've never had a commit like this one?
deep/magic: Commit changes even if not dirty.
Changesets are somewhat magical these days (obviously!); even if they are
not dirtied; they could end up being really, *really* bogus as far as
their on-disk status. The reason, as far as I can tell, is that in
deep/wizardry, we are being very liberal about our modifications to the
on-disk data structures without actually considering whether or not any
other owner of that structure is pending changes to commit. As a result,
we could end up heavily corrupting these structures if we're not careful.
I'm not altering the comments in the file because, frankly, the comments
imply that we should have already been doing this. I just changed the
code to match.
Fixes #4242. Finally! Time to go grab a beer. :3
Tests: +5 working
mad/deep/magic.py | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)