3 ms·
It's not an obsession, and the commit history isn't perfect by any means. But don't underestimate the value of a good commit history, especially if you are usi
by rrwo 4y ago
It's not an obsession, and the commit history isn't perfect by any means.
But don't underestimate the value of a good commit history, especially if you are using git blame to understand a change from several years ago. Wading through small typo fixes gets in the way.
Git encourages you to use branches, and rebasing allows you to squash simple typo fixes and minor changes, so you can review a change with a few commits that are easier to understand instead of a dozen.
Used with cherry picking, you can also move commits to other branches. I often find that bigger features changes turn into multiple branches and PRs, which is easier to review.
The cost isn't very much. Maybe a few minutes at most reorganizing a branch.
It also forces me to review the branch before submitting a PR. Sometimes I catch issues or use that as an opportunity to split into multiple PRs.
- thunky 4y agoThis all makes sense and I don't doubt that it's worth it for you, I guess I just personally don't lean on commit history that much. I use git blame to find who touched the code, but not necessarily why. And during reviews I spent most of the time looking at the totality of the code changes (along with tests and PR notes) rather than deducing what's going on by looking at one commit at a time. Overall I see the history as a log, which is only an artifact and not a product on its own.