7 ms·
You get some of this for free if you create branches and squash merge them when finished. Without needing to think much about commit message, just a few words p
by rejschaap 1y ago
You get some of this for free if you create branches and squash merge them when finished. Without needing to think much about commit message, just a few words per commit is enough. This is good enough for me and I don't need to waste any time thinking about it.
Example commits of something I worked on a few days back:
$ git l feature/character-selection
c54825f 3 days ago Robert Schaap (feature/character-selection) Simplify color picker, fetch current color
d512569 3 days ago Robert Schaap Fix recolor for female, clean up files
6d05ce4 3 days ago Robert Schaap Add color picker to change shirt color
441180b 3 days ago Robert Schaap Show male in editor
17045dc 3 days ago Robert Schaap Remove old character
95772ff 3 days ago Robert Schaap Add characters
Then when I squash merged it I ended up with this commit message:
$ git show HEAD~1
commit be50e0d701d565cebdf4f29e0c9d8030a1a8faf7
Author: Robert Schaap
Date: Mon Mar 24 21:29:20 2025 +0100
Character selection (#14)
* Add characters
* Remove old character
* Show male in editor
* Add color picker to change shirt color
* Fix recolor for female, clean up files
* Simplify color picker, fetch current color
- kqr 1y agoGranted, I'm not the target audience of your commit messages, but they tell me very little about what happens. > Add characters I can probably tell from the code that that's what's happening. But what requirements drove these particular characters? > Remove old character What makes it old? How would I recognise an old character in the future? > Show male in editor Why did male not show before? Was there a bug or a partially implemented feature? > Fix recolor for female, clean up files What does it mean to "fix recolor"? And even worse, what is "clean up files"? What requirements drove this file cleaning? Why were the files unclean in the first place? etc. Commit messages in the style of "fix X" or "add Y" or "remove Z" or "nondescript action on W" are the bane of my existence. They seem so meaningful but they don't tell me anything when I'm trying to trace why a particular bug was introduced – or whether it's even a bug in the first place.
- Cthulhu_ 1y agoYeah I think the most important thing to think about when writing a commit message is the intent; a LOT of people use it as a "work log", describing what they did like "removing a character" or "add color picker". But a commit message needs to describe what the commit does, when applied. A good rule of thumb - also explained on the git site [0] - is to put it in a template like "When applied, this patch will <your commit message>". The grandparent comment is almost there though, using the right tense of "fix" instead of "fixed", the latter being in the work log form of "I fixed such and such". [0] https://git-scm.com/docs/SubmittingPatches/2.2.3#:~:text=Describe%20your%20changes%20in%20imperative%20mood https://git-scm.com/docs/SubmittingPatches/2.2.3#:~:text=Des...
- ahofmann 1y agoYes! Please tell me _why_ the commit happened. The _what_ is in the diff, so almost no need to tell me in the commit message. Often I get commits with some LLM-generated slop in the commit message. It always looks good and always tells nothing. Commit messages like that are garbage.