Resistance Against Git Merge Hell (2015)
Overall tension: clean vs “true” history
- Some see “clean history” as subjective marketing; all info is in the graph and tools like grep/bisect exist, so visual mess isn’t a crisis.
- Others argue dense merge graphs are practically unreadable and harm forensics, review, and blame.
- There’s broad agreement that commit history never fully reflects how code was written; it’s about making later reasoning easier, not preserving every step.
Merge vs rebase
- Pro‑rebase:
- Linear history is easier to understand, review, and bisect.
- Interactive rebase helps turn chaotic local work into clear, logical commits.
- Rewriting private branches is seen as good hygiene; “never rewrite history” is reserved for shared/public branches.
- Anti‑rebase / cautious views:
- Rebasing “invents” intermediate commits that never existed or were tested; squash is preferred to avoid fake states.
- Rebase conflicts can be more painful than merge conflicts, especially across many commits.
- Rewriting shared branches (e.g., default branch) is strongly discouraged due to disruption.
Squash merges and commit granularity
- One camp: always squash into main; nobody cares about the internal noise of feature branches and it keeps main bisectable and simple.
- Another camp: squashing full features throws away carefully curated, atomic commits that help future blame, bisect, and understanding.
- Some advocate a middle path:
- Squash trivial fixups and WIP.
- Preserve meaningful, buildable commits that tell a coherent story.
History viewing and tooling
- Several note that many complaints are about presentation, not storage:
git log --first-parentor--no-mergescan surface only the main sequence.- Visual history can be useful for understanding branch divergence, but many never use it.
- Some wish for better query languages, interactive UIs, and features like “hidden” original commits that survive beyond reflog/GC.
Workflow, roles, and environments
- Debate over whether contributors should handle rebasing to keep PRs trivially mergeable vs this being a maintainer duty.
- Views differ on production/staging branches; some see separate production branches and rebasing as useful, others argue deployments should reuse the exact staging artifacts instead of new builds.