[skydhash]

> I've never seen someone write decisions or the intent they started with in commit messages

You may not have seen enough good repos. The following is an example commit from freebsd

https://cgit.freebsd.org/src/commit/?id=ac5ff2813027c385f903...

A proper email is like an email. You have the first line as the subject and it may be enough to explain the intent of the diff. But sometimes it’s not enough and you add more details in the body. I strongly believe that people who write the WHAT again don’t know that there’s a diff attached to the commit and think of them a separatete objects. GitHub and VSCode do not really help in that regard.

[codethief]

> The following is an example commit from freebsd

The Linux kernel is another great example. Random commit from yesterday:

https://github.com/torvalds/linux/commit/d56b5d163458c45ab8f...

[no-name-here]

Obviously projects have their own standards around comments, but as the why is apparently important and non-obvious, would it be even better for the ‘why’ to be a code comment in order to understand why code exists without looking through the git history for each line?

[keybored]

> A proper email is like an email.

A proper commit message is like an email?

[vidimitrov]

This looks very good. Thanks for sharing. I can only imagine how much discipline it takes to write these kinds of commits manually.

[skydhash]

Is it discipline?

When you think of the patch as an unit of idea and the commit as the means to convey that idea, it takes the same amount of effort to write an email message.

BTW you do not have to write those for every single commit. You can always rebase interactively and create a final set of commits for sharing. No one cares about what’s in your local copy of the repo.

[keybored]

You don’t have to look far to find it. Git and Linux, the two first Git-based projects, work like this.

You could have found this if you did just a little research before declaring an open standard.

[svstoyanovv]

I think this requires discipline. The good thing is that we have coding agents, but again, you need a standard to tell the agent what to always look for, how to find it, and to describe your modules properly (even Claude Opus 4.6 makes mistakes when doing hops when tracing code spanning files). Btw, there is also a paper on this issue, Google released it recently