Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linus: please write good git commit messages

github.com

Post reply on HN
Print view View original

31–40 of 58 posts

Re: Linus: please write good git commit messages

#31

Post by telemachos »

barumrho wrote: post #30
timknauf wrote: post #12

I'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?

I hate to ask an off-topic question here, but is it considered good/bad practice to word-wrap plain text emails?

I think so, yes. Certainly, something like this is very common in Mutt configuration files:

    set editor="vim -c 'set tw=75 ft=mail noautoindent'"
The 'set tw=75' bit, sets the text width to 75 columns.

Re: Linus: please write good git commit messages

#32

Post by andrewflnr »

arkitaip wrote: post #16
drivingmenuts wrote: post #7

Earlier quoted context omitted.

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.

Upvoting itself might be all you need.

Re: Linus: please write good git commit messages

#33

Post by prodigal_erik »

MostAwesomeDude wrote: post #20
zacharyvoase wrote: post #18

Not 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 consi…

I would prefer to see that rationale in the comments or some implementation doc or something. In the git history it's eventually going to be troublesome to unearth, unless the change remains intact enough for "git blame" to give you a pointer to that old commit, or your whole team standardizes keywords for more searchable commit messages. And if your team does have a way to find that explanation, you then need some way for them to discover whether it has become inaccurate over time.

Re: Linus: please write good git commit messages

#34

Post by itmag »

mapleoin wrote: post #8
rmc wrote: post #5

Am I the only one that thought this was someone asking Linus Torvalds to write better commit messages?

The submission text was right, though. It would have been a comma instead of colons if "Linus" were in the vocative case.

Et tu, Line?

Re: Linus: please write good git commit messages

#35

Post by dustingetz »

we use

  ISSUE-1234: persist client-side display configuration to settings
and our issue tracking and code review software recognize issue numbers and hyperlink to the actual issue, with comments, reported-by, description, environment, replication steps, related changesets, code reviews, etc. pretty great especially considering multiple commits on the same issue which can't be rewritten into one commit because they've already been pushed. it also makes `git log --oneline` useful.

Re: Linus: please write good git commit messages

#36

Post by dustingetz »

zacharyvoase wrote: post #18

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

  > If I need to write several paragraphs about 
  > the changes I'm making, it's definitely too 
  > large a commit.
careful, this is subjective, and a lot of people consider it best practice to commit in small chunks but rewrite local history right before we push to squash everything into one changeset for the issue. the idea being it keeps the master history high level which is more useful when looking at other-peoples-commits.

Re: Linus: please write good git commit messages

#37

Post by wnoise »

njonsson wrote: post #15
jacknagel wrote: post #14

Earlier quoted context omitted.

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 $@

You might be interested in the program "par", which uses dynamic programming to optimize the line breaks, and can automatically handle such things as text prefixed by "> ".

http://www.nicemice.net/par/

Re: Linus: please write good git commit messages

#38

Post by adambyrtek »

dustingetz wrote: post #35

we use ISSUE-1234: persist client-side display configuration to settings and our issue tracking and code review software recognize issue numbers and hyperlink to the actual issue, with comments, reported-by, description, environment, replication steps, related changesets, code reviews, etc. pretty great especially considering multiple commits on the same issue which can't be rewritten into one commit because they've…

Is this usually the case that exactly one commit maps to a single issue? I'd rather expect a whole branch to cover one issue (unless it's completely trivial). In this case, repeating the same issue number in every commit message on a branch doesn't seem very useful.

Re: Linus: please write good git commit messages

#39

Post by caf »

barumrho wrote: post #30
timknauf wrote: post #12

I'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?

I hate to ask an off-topic question here, but is it considered good/bad practice to word-wrap plain text emails?

This might not actually be that off-topic, because I think the underlying reason that git commit messages are stored line-wrapped is for ease of sending them unmolested through email.
Post reply on HN