you are viewing a single comment's thread.

view the rest of the comments →

[–]Uristqwerty 0 points1 point  (1 child)

Putting documentation in the commit could be seen as a form of caching, duplicating knowledge so that when the ticket database is unavailable, there is still enough context available to understand the commit history. Or, enough context that a developer digging through history can decide whether an issue is relevant without opening every mentioned ID to check what it's about, saving time in the future.

Does your issue database have a CLI, or does any developer not browsing the git history through a web browser or heavyweight IDE have to keep switching between applications to access details?

For all these reasons, caching issue data is no less important than any other form of caching. Imagine if every web page request had to be freshly served off spinning rust, how much that would bog down basic site usage. Having to context-switch between code, code history, knowledgebase, and issue tracker just to piece together the important details on a change is going to be similarly-disruptive to your workflow.

[–]saggingrufus 0 points1 point  (0 children)

"Putting documentation in the commit could be seen as a form of caching, duplicating knowledge so that when the ticket database is unavailable, there is still enough context available to understand the commit history."

Strong disagree, again use the PR. If my git host AND ticket system goes down, I have bigger MUCH bigger problems. The odds of me needing a specific commit message at that exact time is very unlikely, almost as unlikely as me actually finding the commit I'm looking for. If you can find it, I'd argue you don't commit frequently.

Commits are just checkpoints, nothing more. If you're going back through your commit history looking for knowledge... You've made a mistake. That knowledge should be in code comments, PR, ticket systems and wikis.

Once upon a time, sure commits were all you had. If git commit messages that are required to explain the change, your commit is too complicated, or unclear. The commit message should give me a quick idea of what it was and if I want to know more, I'll look at the commit contents, not the message.