1. 88
  1. 27

    I love these commit messages!

    Someone at my employer created an internal site called “gitblog”, which presents commit messages longer than 1000 characters as blog entries (pulled every 30 minutes from selected repositories). It makes for great reading, and it’s a great way of celebrating good commit messages.

    1. 9

      That’s a great idea!

      I’d implement that at work, but I’m the only one who writes messages longer than “FIXED BUG”. :(

    2. 15

      I wish I could buy a beer for the Emacs developer who decided that nbsp should be visually called out with a special underline in your buffers.

      1. 7

        Was it definitely an nbsp? For all its wonderful verbosity, the commit message doesn’t actually say what the offending character was.

        ETA: I see that the blog post does mention nonbreaking spaces, albeit only in passing.

        1. 4

          I also found it strange that he doesn’t mention it explicitly… Oh well, clearly it wasn’t that important ;^)

      2. 12

        I really appreciate this kind of commit message. There’s some very good ones in the Mercurial logs too:

        Long commit messages aren’t that atypical. Have a stroll through the logs:


        There’s no length limit on commit messages and commit messages are mostly out of the way. Most VCSes have a way to only show you the first line. So if you want summaries, that’s what the first line is for. If you want the full story, that’s what the body is for.

        Combined with annotate/blame, commit messages can be very helpful source-level documentation. Nobody has ever complained about too much documentation, and commit messages are the perfect time to document what happened because it’s one of the few times where our tools actually force us to write something in order to proceed. As long as we’re being forced to write something, write something good and informative.

        Mercurial inherited this style of commit messages from Linux email-based code review (the Mercurial originator was a kernel hacker), because in that workflow your commit messages are kind of a persuasive essay for why your commit should be accepted. I believe that writing commit messages with that kind of goal in mind, thinking “why should you take this commit?” is a good motivator for writing something good and useful.

        1. 4

          Musl has some really nice commit messages: https://git.musl-libc.org/cgit/musl/log/

          1. 2

            In the sad reality outside the OSS projects, no one has a time for that (or at least thinks so), but more importantly it’s just not being taken seriously or even read, as people mostly just skim over the headers of git log.

            I tried to show or apply many “good practices” or other nice patterns in terms of source control (and code management in general). It always fails, the amount of “black matter developers” (look up “the world runs on Java 8” article) is way larger than people can imagine. And I’m not okay with that, even making talks and workshops does not help at all - devs just want to click ok and get on with things

            1. 6

              In the sad reality outside the OSS projects, no one has a time for that (or at least thinks so), but more importantly it’s just not being taken seriously or even read, as people mostly just skim over the headers of git log.

              I can’t count the number of times where I saw some seemingly code at work that’s buggy which I don’t understand at all. I’m so happy when a quick “git blame” and showing of the commit message tells the story of why this code is the way it is. At the very least the commit message should include a ticket number, but ideally it explains why the change was made. This context is often exactly what you need to fix the code to do what was intended. Without such context, I’m sure I would mess things up (or undo some attempted half-fix from a colleague, re-introducing the original bug).

              For this reason (and often times, I’m the guy who has to dig back and then finds his own commit and thinks “oh yeah, that’s what was going on”) I try to write good commit messages. It’s the neighbourly thing to do for your fellow committers (and yourself), and has little to do with OSS versus proprietary code. If you spend two or three hours fixing a bug or implementing a new feature, I think it’s warranted to spend 5 to 10 minutes crafting a good commit message. And even if it only took you 5 minutes, if you have even the slightest hunch that someone not as deep into the code base as you would need more time to understand, just make the effort.

              Even if 90% of the commits don’t get read like a novel, that 10% of commits surrounding problematic or tricky code are worth it.

              1. 3

                The mentioned article that uses the term “black matter developers” is https://veekaybee.github.io/2019/05/10/java8/.

                1. 1

                  The term is “dark matter”, a reference to the concept from physics, not “black matter”, even though black is the darkest possible colour & I can see how this could be confusing to somebody for whom English is not their first language.

                2. 1

                  I’ve got so much to learn. I can’t imagine diagnosing and fixing that bug in just an hour!