11 ms·
Most compelling argument is to explain "why" not "what". It's what I strive for in commit messages - in order to reconcile changes with the original intent and
by ed-209 3y ago
Most compelling argument is to explain "why" not "what". It's what I strive for in commit messages - in order to reconcile changes with the original intent and enable identification of bugs created through misunderstanding.
But commit history gets messy quick...I have food for thought.
- ssnri 3y agothis is why i dislike refactoring unless there’s a legitimate change to the functionality and not just a rearrangement. Leave the history alone for us bug spelunkers
- lazyasciiart 3y agoRefactoring doesn’t lose history. Mass migrating between source control systems loses history
- yuliyp 3y agoIt makes that history harder to read. The same piece of logic can move across files and modules and functions over the years. While it's possible to go past each of them and trace that code past those moves, it takes time and effort to do so.
- lazyasciiart 3y agoI’m normally the one doing that historical spelunking, so I’m also a fan of refactors or rewritten methods that reduce the need to go back and figure out why the code is there. But I’m usually also the one doing that: maybe if other people around me did more refactoring I’d start hating it too!
- hinkley 3y agoThe biggest problem I’ve run into in this respect is reformatting and behavior changes in the same commit. It’s not all that hard to trace back as long as nobody does this. It’s why I hate squashing.
- cwalv 3y agoYou can squash commits with squashing unrelated commits.