4 ms·

I wholeheartedly disagree. Bug tracker? It can change. Reviews discussion? The tool can change. You get the point. As an added pain point, I don't want to jug

I wholeheartedly disagree. Bug tracker? It can change. Reviews discussion? The tool can change. You get the point. As an added pain point, I don't want to juggle different tools to get the whole picture about changes. I don't want to copy/paste a Jira ticket reference in my browser from my terminal to get the reasoning about the change. I don't want to copy/paste a bugtracker ID to get the reasoning about the change. Commit messages are here for a reason, and it is to document the change. I find them invaluable when digging through a codebase with plain git tools, tig, or the git integration of an IDE. Conversely, this is why I hate squashes of PRs of more than X commits. Just no.

groestl 4y ago
> this is why I hate squashes of PRs I like them because of the linear history, but the commit message should keep the explanation for _all_ the changes.
- tuetuopay 4y ago
  For this, I often configure repos to only accept "fast-forward merges", as to keep a linear history. The added benefit is increased by good splitting of commits as conflicts will be resolved commit by commit rather than the whole PR with a possibly huge conflict to solve.
usrusr 4y ago
But commit messages can also be too fine-grained, at least if you are not into the squashing game. And a level of conciseness that is valuable in commits might be a little too short for truly meaningful context years later. My preferred pattern is some "why" in the message, as a soft "should", and a external reference to some potentially longer and perhaps not so fine-grained ticket/story/bugtracker-id as a much stronger "should". That's where longer form prose has its place, or some media, and most importantly after the fact amendments without the hassle of history rewriting. And once that pattern is 80% established, even the emotional outlet of an occasional "whoopsie" message can be totally worth the cost, if it's actually "whoopsie (WHYJIRA-12345)" Anything occasionally gets lost. (some languages have surprisingly useful decompiles..) It's probably best if all approaches are taken in parallel. And taken reasonably well (as opposed to gold plating), enough to be workable alone in a pinch but decidedly not fully redundant. Comments, commits and out-of-band tickets all have their place and neither is a good substitute for the others. Allow them to complement each other, and strive for just enough overlap to make losses somewhat tolerable.

groestl 4y ago

> this is why I hate squashes of PRs I like them because of the linear history, but the commit message should keep the explanation for _all_ the changes.

tuetuopay 4y ago
For this, I often configure repos to only accept "fast-forward merges", as to keep a linear history. The added benefit is increased by good splitting of commits as conflicts will be resolved commit by commit rather than the whole PR with a possibly huge conflict to solve.

usrusr 4y ago

But commit messages can also be too fine-grained, at least if you are not into the squashing game. And a level of conciseness that is valuable in commits might be a little too short for truly meaningful context years later. My preferred pattern is some "why" in the message, as a soft "should", and a external reference to some potentially longer and perhaps not so fine-grained ticket/story/bugtracker-id as a much stronger "should". That's where longer form prose has its place, or some media, and most importantly after the fact amendments without the hassle of history rewriting. And once that pattern is 80% established, even the emotional outlet of an occasional "whoopsie" message can be totally worth the cost, if it's actually "whoopsie (WHYJIRA-12345)" Anything occasionally gets lost. (some languages have surprisingly useful decompiles..) It's probably best if all approaches are taken in parallel. And taken reasonably well (as opposed to gold plating), enough to be workable alone in a pinch but decidedly not fully redundant. Comments, commits and out-of-band tickets all have their place and neither is a good substitute for the others. Allow them to complement each other, and strive for just enough overlap to make losses somewhat tolerable.