[ed-209]

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]

this 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

[hinkley]

The 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]

You can squash commits with squashing unrelated commits.

[lazyasciiart]

Refactoring doesn’t lose history. Mass migrating between source control systems loses history

[yuliyp]

It 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]

I’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!