4 ms·

i don't get why so many people cannot write good commit messages. 72 chars is a very useful limit. if you cannot describe it in 72 chars, you should commit more

• thomseddon 14y ago
  Linus Torvalds himself is an advocate of very descriptive commit messages: https://github.com/torvalds/subsurface/blob/master/README#L161 https://github.com/torvalds/subsurface/blob/master/README#L1... And more explicitly: https://github.com/torvalds/linux/pull/17#issuecomment-5659933 https://github.com/torvalds/linux/pull/17#issuecomment-56599... We have been moving towards commit messages similar to those used in the kernel development (i.e. longer, descriptive) and it has proven very useful indeed
  • monsterix 14y ago
    Yes, both from search index-ability and training point of view.
  • bittersweet 14y ago
    Tim Pope has written about the model commit message [1] and why you should use a short first line, I'm a big believer in this setup and it's done wonders for the readability of my commit messages. Github itself even uses these rules [2] so I think it's slightly annoying people don't follow them as it looks worse if you use long first lines on the website. [1] http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa... [2] https://github.com/blog/926-shiny-new-commit-styles https://github.com/blog/926-shiny-new-commit-styles
    • nirvdrum 14y ago
      Keep in mind "it looks worse if you use long first lines on the website" is a completely arbitrarily imposed issue from GitHub. A while back they just wrapped the text and all was right in the world. Now they truncate the message and it looks like garbage.
      • dasil003 14y ago
        However in this case "the website" is just one of dozens of tools out in the world. 50-character summary messages are incredibly awesome across the board, and everyone should learn to write them.
        • nirvdrum 14y ago
          I cannot disagree any more. I haven't used a terminal that can't wrap in probably 15 years. The point of a commit message is to convey information. If you could point me to a study or something showing people retain info or learn better with a 50 char limit, awesome. But until then, I stand by it being a completely arbitrary restriction.
          • dasil003 14y ago
            Sorry, but your opinion is wrong and harmful. The point of the summary line is a succinct and scannable summary of the commit. Open up any git GUI; gitk or SourceTree are my two favorite. If you keep your summary lines under 50 characters you can quickly scan a maximal number of commits. Detailed descriptions are great and should be included as well for any substantial commits, but that is not what you want in the summary. That should be added in separate paragraphs after the summary line. This is not arbitrary, and it has nothing to do with the ability to line wrap, it's about efficient communication faced with a history of tens or hundreds of thousands of commits over time.
  • vidarh 14y ago
    I don't see Linus suggestion as disagreeing with ibotty. Linus uses a short "headline" followed by additional useful information starting from line 3, and insists on a line length of no more than 74 characters, and he wants the header to be "really meaningful [...] and should summarize the change in one readable line of text" Long commit messages are good. But a good first line is essential, since, as Linus points out, that is what gets shown by default by a lot of tools.
    • ibotty 14y ago
      when writing this i forgot that the first line should be not longer than 50 chars or so. that might have been his point. vim's syntax highlighting will warn you when you write too much, so i usually do not really notice the length (afair emacs does as well).
• nirvdrum 14y ago
  On the other hand, I'm tired of short commit messages that are almost completely devoid of anything useful because the author wanted to adhere to an arbitrary restriction. It feels like the mentality that all comments are evil and can be fixed by better method names. The short message first, longer message after is a pretty good middle ground. But if that first sentence is useless, I'd rather just have a single commit message that accurately describes the commit.
• calinet6 14y ago
  > and the useful info that comes after it can of course be included in the commit. but starting at line 3! I think this is the part people don't understand. The first line should be < 72 chars. After that (and a blank line), write as much as you want.