3 ms·
I've always advocated maintaining true, "messy" history (in git) amongst my teams. I know it's controversial, but anecdotally, verbose history has helped me und
by EvanDotPro 5y ago
I've always advocated maintaining true, "messy" history (in git) amongst my teams. I know it's controversial, but anecdotally, verbose history has helped me understand the nuance of otherwise opaque changes and decisions so many times that I can't help but cringe when a bunch of context is lost to squashing for the sake of a "clean" history. Many of the technical arguments for squashing tend to be things that can be mitigated by simply traversing merge commits only.
- mook 5y agoWouldn't _not_ squashing be sufficient, rather than having to keep all of the messy commits? That is, would you be satisfied with modifying history such that the commits are logically separate, even if it's not how the code actually evolved? I don't understand the desire to squash every PR into one commit each either…
- EvanDotPro 5y agoSure, I'm not a total purist about it. What's important to me is maintaining the logical progression of a change, even if it includes some dead ends, non starters, or mistakes. If you want to amend commits for a typo, code style fix, or otherwise inconsequential change that doesn't add any useful context for future developers, by all means go for it.
- ajb 5y agoTBH That's because squashing is the quick and dirty option. If I have time, I prefer to rebase and organise the changes into a number of commits each addressing one concern. The only thing that gets removed is bugs and typos which I were introduced on that feature branch, and then fixed again. No need for those to go upstream - it would just add noise.