6 ms·

Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they we

by xp84 7mo ago

Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. As a manager, one of the first things I do is make sure that the PR titles (the PR text becomes the commit messages in squash-merging workflows) at minimum begin with a ticket number. Then we can later read both the intention and the commentary on it.

PUSH_AX 7mo ago
> Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.
- macintux 7mo ago
  The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. And for old enough code, the author may not be available, or more likely doesn't remember.
  - PUSH_AX 7mo ago
    Fine, but none of that is in a normal commit message, lets be real...
    - mgfist 7mo ago
      Which circles back to why it's important for leadership to tackle this
      - PUSH_AX 7mo ago
        Yes, but not in the form of commit messages, the parent comment described things better suited to jira tickets, documentation etc. It feels like we're trying really hard to stretch the utility of commit messages here...
        macintux 7mo ago
        Mainly I was pushing back on: the code is the "truth" I don't feel that is an accurate statement for any complex system.
        PUSH_AX 7mo ago
        I don't like complex systems, and I work hard not to create them.
        mgfist 7mo ago
        Sure but code can't capture everything. Maybe with enough comments I guess, but not code alone. For example, code won't tell you that this feature was timeboxed hence this edgecase was not supported
        hluska 7mo ago
        And a commit message would convey that?
        mgfist 7mo ago
        It could, or maybe the ticket does.
        xp84 7mo ago
        Having dumb or nonexistent commitment messages has 0% chance of communicating anything. If someone has at least made an effort, a future someone will be able to identify some of the following: 1. What project in general the change was associated with (it may not be obvious from the files changed in this single commit) which can indeed tell you how well it was spec’d- maybe you’ll even find the technical plan. 2. Possibly a hint of how the author intended it to work, or a clue about their misunderstanding. For example, the commit may have changed a function to accept a null argument to “solve” some other problem, but now you know that null passing through here is harmful, well thanks to the commit info, you know that you have to account for the problem that dev was “solving” if you don’t allow the null here. Without that you’d just revert the change and cause the other bug to regress.
- wreath 7mo ago
  And what of the original author is not there anymore?
  - PUSH_AX 7mo ago
    The world will not end. I’ll get there.
- agateau 7mo ago
  The code is the present truth, the commit messages can inform you about how it got turned into this truth. Interestingly, I recently wrote a short article about this: https://agateau.com/2026/on-commit-messages/ https://agateau.com/2026/on-commit-messages/
  - cratermoon 7mo ago
    Your argument on conventional commits is something I've come to agree with. There are even tools that can generate release notes from conventional commits, and they are premised on the same mistake.
- deleted 7mo ago
  [deleted]
alt_422568 7mo ago
> you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.
- PUSH_AX 7mo ago
  That sounds clever until you remember tools exist to solve actual problems. Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?
  - alt_422568 7mo ago
    Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4] If enough of the following apply strongly enough to your project: * Very small codebase * A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review * Not doing anything technically challenging * You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane. I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6] > Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook. [0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=log https://git.postgresql.org/gitweb/?p=postgresql.git;a=log [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.ffmpeg.org/gitweb/ffmpeg.git/log https://git.ffmpeg.org/gitweb/ffmpeg.git/log [3] https://github.com/openjdk/jdk/commits/master/src/hotspot https://github.com/openjdk/jdk/commits/master/src/hotspot [4] https://github.com/openssl/openssl/commits/master/ https://github.com/openssl/openssl/commits/master/ [5] https://spinroot.com/gerard/pdf/P10.pdf https://spinroot.com/gerard/pdf/P10.pdf The Power of Ten - Rules for Developing Safety Critical Code [6] https://tigerstyle.dev/ https://tigerstyle.dev/

by xp84 7mo ago

PUSH_AX 7mo ago

> Useless? So you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? Personally no, the code is the "truth". If I need more I'm going to open a dialog with the author, not spend time trying to interpret a 7 word commit message, "good" or otherwise.

macintux 7mo ago
The code can only convey what is being done (and then, in some cases, only superficially). It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code. And for old enough code, the author may not be available, or more likely doesn't remember.
- PUSH_AX 7mo ago
  Fine, but none of that is in a normal commit message, lets be real...
  - mgfist 7mo ago
    Which circles back to why it's important for leadership to tackle this
    - PUSH_AX 7mo ago
      Yes, but not in the form of commit messages, the parent comment described things better suited to jira tickets, documentation etc. It feels like we're trying really hard to stretch the utility of commit messages here...
      - macintux 7mo ago
        Mainly I was pushing back on: the code is the "truth" I don't feel that is an accurate statement for any complex system.
        PUSH_AX 7mo ago
        I don't like complex systems, and I work hard not to create them.
        mgfist 7mo ago
        Sure but code can't capture everything. Maybe with enough comments I guess, but not code alone. For example, code won't tell you that this feature was timeboxed hence this edgecase was not supported
        hluska 7mo ago
        And a commit message would convey that?
        mgfist 7mo ago
        It could, or maybe the ticket does.
        xp84 7mo ago
        Having dumb or nonexistent commitment messages has 0% chance of communicating anything. If someone has at least made an effort, a future someone will be able to identify some of the following: 1. What project in general the change was associated with (it may not be obvious from the files changed in this single commit) which can indeed tell you how well it was spec’d- maybe you’ll even find the technical plan. 2. Possibly a hint of how the author intended it to work, or a clue about their misunderstanding. For example, the commit may have changed a function to accept a null argument to “solve” some other problem, but now you know that null passing through here is harmful, well thanks to the commit info, you know that you have to account for the problem that dev was “solving” if you don’t allow the null here. Without that you’d just revert the change and cause the other bug to regress.
wreath 7mo ago
And what of the original author is not there anymore?
- PUSH_AX 7mo ago
  The world will not end. I’ll get there.
agateau 7mo ago
The code is the present truth, the commit messages can inform you about how it got turned into this truth. Interestingly, I recently wrote a short article about this: https://agateau.com/2026/on-commit-messages/ https://agateau.com/2026/on-commit-messages/
- cratermoon 7mo ago
  Your argument on conventional commits is something I've come to agree with. There are even tools that can generate release notes from conventional commits, and they are premised on the same mistake.
deleted 7mo ago
[deleted]

alt_422568 7mo ago

> you never use “git annotate” or your IDE to see who wrote a line of code whose purpose puzzles you, and go to the commit message to see what they were trying to accomplish? This is invaluable to me as long as commit messages are clear. You're thinking like someone with a mature understanding of version control. Plenty of developers seem set on going their whole careers using git like beginners.

PUSH_AX 7mo ago
That sounds clever until you remember tools exist to solve actual problems. Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop. Some teams don't have enough upstream issues that they need to lean on git in the way you do maybe?
- alt_422568 7mo ago
  Think of a major FOSS project in a technically challenging domain. Every single one of them insists on proper version-control discipline. [0,1,2,3,4] If enough of the following apply strongly enough to your project: * Very small codebase * A one-person project, or a very small team where everyone can be expected know the entire codebase and you don't bother with code-review * Not doing anything technically challenging * You don't care about the other advantages of disciplined version-control, such as the ability to meaningfully revert a commit, or to more easily associate a bug with a feature then sure, you can get away with sloppy use of version control, or even no version control at all. The same applies to various other aspects of software development. Skillful structuring of code doesn't matter in a very small codebase. The drawbacks of dynamically typed languages aren't a real problem in small codebases. Documentation might not be worth writing up. The list goes on. It makes sense that there's generally less call for the various aspects of the 'craft' of software development in such projects. The same applies to other disciplines. You don't bother with CFD modelling for your paper airplane. I'm not convinced there's really any upside to the sloppy approach though. Developers with the skill to write decent commit messages (plenty of developers lack this), and otherwise make skillful use of version control, tend to make it a habit and always apply the disciplined approach. It's like NASA's old rules for software: The rules act like the seat-belt in your car: initially they are perhaps a little uncomfortable, but after a while their use becomes second-nature and not using them becomes unimaginable. [5][6] > Treating simple workflows as inferior is like saying a carpenter is amateurish for not using every attachment in the workshop I see it differently: what I'm proposing is developing mastery over a core tool of the craft, and applying it consistently in our work. We'd expect the same from a competent carpenter or cook. [0] https://git.postgresql.org/gitweb/?p=postgresql.git;a=log https://git.postgresql.org/gitweb/?p=postgresql.git;a=log [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/ https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... [2] https://git.ffmpeg.org/gitweb/ffmpeg.git/log https://git.ffmpeg.org/gitweb/ffmpeg.git/log [3] https://github.com/openjdk/jdk/commits/master/src/hotspot https://github.com/openjdk/jdk/commits/master/src/hotspot [4] https://github.com/openssl/openssl/commits/master/ https://github.com/openssl/openssl/commits/master/ [5] https://spinroot.com/gerard/pdf/P10.pdf https://spinroot.com/gerard/pdf/P10.pdf The Power of Ten - Rules for Developing Safety Critical Code [6] https://tigerstyle.dev/ https://tigerstyle.dev/