> my first knee-jerk reaction wouldn't be "this is for pretending to be human"...
"Write commit messages as a human developer would — describe only what the code change does."
"Write commit messages as a human developer would — describe only what the code change does."
Writing and reading paragraphs of design discussion in a commit message is not something that seems common.
And of course tickets can be private, so even if the data survived migration, you may not have access to it (principle of least privilege and all that).
What you're describing here is a design. The most important parts of a design are the decisions and their reasoning.
e.g. "we decided on tool/library pattern X over tool/library/pattern Y because Z" – that is a design, usually discussed outside (and before) a commit message.
You discuss these decisions with others, document the discussion and decision, and then you have a design and can start writing code.
Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?
Random example:
Provide a new syscall which has the only purpose to yield the CPU after the kernel granted a time slice extension.
sched_yield() is not suitable for that because it unconditionally schedules, but the end of the time slice extension is not required to schedule when the task was already preempted. This also allows to have a strict check for termination to catch user space invoking random syscalls including sched_yield() from a time slice extension region.
From 99d2592023e5d0a31f5f5a83c694df48239a1e6c
In your example, for example, where was the issue tracked before the code was written? The format you linked makes it difficult to get the history of the issue.
Let me ask you this: suppose you have a task that needs to be done eventually, and you want to write down some ideas for it, but don't want to start coding right now. Where do you put those ideas? How do you link them to that specific task?
Email is the review process, and commits contain enough information that git blame can get you a reasoning - it doesn't require you checking the email archive. Rather than a dead ticket that no longer exists.
I can also supply you a list of companies that make use of git's builtin features if you like. But thats probably not relevant to discussing management techniques.
https://cgit.freebsd.org/src/commit/?id=407b1e4980189252fade...
You can find more example there
VS Code has a setting that promises to change the prompt it uses to generate commit messages, but it mostly ignores my instructions, even very literal ones like “don’t use the words ‘enhance’ or ‘improve’”. And oddly having it set can sometimes result in Cyrillic characters showing up at the end of the message.
Ultimately I stopped using it, because editing the messages cost me more time than it saved.
/rant
[edit] Never mind, find in page fail on my end.
> Commit f9205ab3 by dkenyser on 2026-3-31 at 16:05:
> Fixed the foobar bug by adding a baz flag - dkenyser
Because it already identified you in the commit description. The reason to add a signature to the message is that someone (or something) that isn't you is using your account, which seems like a bad idea.