[PUSH_AX]

> 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.

[agateau]

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/

[cratermoon]

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.

[macintux]

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]

Fine, but none of that is in a normal commit message, lets be real...

[mgfist]

Which circles back to why it's important for leadership to tackle this

[PUSH_AX]

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...

[rightofcourse]

Yes, we are on our third ticketing system on our team with dead refs to old issues. PR without a commit documenting why you need a change does not normally get approved and helps a lot also at present and future review time. Lots of value for new devs to see how thinking went and why something exist and not something else etc.

Documenting it also forces people to think why they are adding a change in the first place. Code added without purpose becomes dead weight and tech debt.

[cratermoon]

You'll at least need the discipline to include the ticket ID in the message. Links to documentation are ok, but they will likely rot and even if they don't the content may change such that it no longer accurately reflects the commit changes.

[account42]

So rather than commit messages that stay in the repo you want the information in a place where its lost by the next buck tracker migration?

[PUSH_AX]

Look, I'll make this easy to understand. The parent comment that this stems from said:

> It can't convey what decisions were made, what alternatives were discarded, what business motivations may have led to that code.

If you're advocating this should all go in commit messages then I don't know what to say that I haven't already, it objectively doesn't belong there. The end.

[macintux]

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]

I don't like complex systems, and I work hard not to create them.

[wreath]

And what of the original author is not there anymore?

[PUSH_AX]

The world will not end. I’ll get there.