The Lost Art of Commit Messages

Just as you'd expect from an LLM, it hallucinates a description that overfits the average commit message. It doesn't make a good summary of what changed, and most importantly (though I don't expect it to) why it changed, which is what I need in a commit message.

  Address structural issue with code contributions
  
  In some cases, it's possible to end up with commit messages that carry
  very little value. Unfortunately, while the minimum is clearly
  insufficient, it is possible to "expand" the minimum into a specific
  format without substantially improving the quality of the commit
  message. For example, a substantial refactor can easily just be
  described as a list of the changes that it included, rather than a
  rationale for why it was done (which is not readily apparent from the
  change itself).
  
  In the long run, problems involving people can be improved by process,
  but cannot wholly be solved by them. Pernicious failures need to be
  acted upon directly. Demonstrating the value of good commit messages is
  often a better driver of improvements than a template that is a chore
  to fill out.

  Also, reconsider column-based hard-wrapping entirely,
  and consider wrapping mostly on punctuation,
  or other reasonable opportunities when it gets a bit long
  and you don’t really want to insert punctuation.

  This is not without its drawbacks and limitations—
  most software when rewrapping won’t cope with trailing em dashes,
  and you’ll end up with extraneous spaces when the lines are merged,
  even though this is *always* how wrapping has worked around dashes.

  Over time, this will definitely influence your writing style.
  Your sense of æsthetics will push you to reword sentences,
  because otherwise the edge is too ragged for your liking,
  and at some point you’ll see a pattern in a paragraph,
  and feel an uncontrollable urge to continue it,
  and you’ll waste a bunch of time tweaking,
  and maybe no one will appreciate it.
  But you’ll appreciate it.
  It’ll be fun.
  Mostly.

  But seriously, you *will* become more aware of things like clause length,
  and your writing will probably improve.

  And after writing verbosely for a long time,
  you’ll focus on concision,
  and that’ll be another challenge.
  And it’ll be fun too.
  Mostly.

  Then probably someone will take over your pet docs project,
  and mandate an autoformatter that rewraps it to 59 columns.
  Stubbornly, in the quiet of your mind, you’ll make it work.
  It’s a greater challenge, but you won’t lack determination.
  Style guides come, and style guides go; when this one goes,
  your lines can remain the same, needing no fixing, perfect.

  —⁂—

  And really, just look at how the last paragraph of the parent comment looks,
  before and after:

      Finally, commit comments definitely should have jokes in them. This is
      actually more critical than wrapping them at 72 characters.

                                      —⁂—

      Finally, commit comments definitely should have jokes in them.
      This is actually more critical than wrapping them at 72 characters.

  Much more beautiful, is it not?

Besides, a few passes refactoring and your git history is ruined. No way you’ll find the original commit within any reasonable time frame.

If I move the code to another function, your original commit message will be hard to trace. If the code was commented, the comment would have been moved along. If the code was readable, you don’t need the comment or the commit message.

One of the easiest ways to start there is to adopt PR-based review systems, where any number of commits can get pushed to a git repository and then reviewed as a single block. This is fairly inflexible, but it is very simple to get started with (no need to learn any special rebasing commands, just add, commit, add, commit, push). Most git forges allow you to do squash merges, so everything in the PR will become a single commit, usually with the PR description as a commit message. Then you can refine the commit and commit message during the review process.

There are better tools out there, but in my experience, this is the quickest way to get started for most teams, especially as you're probably already using a forge that allows you to do all of this already.