The post is a short guide to Git’s `rerere` feature, short for “reuse recorded resolution.” When enabled, Git remembers how you fixed a conflict and can apply that same fix automatically if it sees the same conflict again later. In theory that sounds like a universal quality-of-life improvement for rebases and merges. In practice, most experienced commenters landed on a narrower conclusion: `rerere` is great when you are resolving the same conflict pattern across many similar branches or repeated backports, but it is not a magic fix for normal single-branch development.
For engineering leaders, this is a reminder that tooling tweaks help, but recurring merge pain is usually a workflow smell. If `rerere` feels essential, you may be paying hidden tax for branch topology, review bottlenecks, or release process complexity.
Mostly positive about learning a useful Git feature, but pragmatic rather than evangelical. People liked `rerere` as a niche power tool while stressing that chronic conflict pain usually comes from branch workflow and team process, not from forgetting one config flag.
01 `rerere` shines in branch-heavy organizations that keep many semi-diverged code lines alive at once.
The repeated-conflict pattern shows up when bug fixes and security fixes must be cherry-picked across release branches, hardware variants, or long-lived dev branches. In that world, `rerere` is valuable because it amortizes a bad process you cannot quickly escape. Several comments go further and argue that keeping variability inside one trunk with mechanisms like `#ifdef` can be healthier than hiding divergence in dozens of branches, because breakage is surfaced immediately instead of months later during backports.
If the same conflict keeps coming back, you probably have a branch topology problem first and a Git ergonomics problem second. `rerere` saves time, but it also exposes how expensive your release model has become.
02 `--force-with-lease` is the practical companion to rebase-heavy workflows because it protects against clobbering remote work you did not know existed.
The key point is not multi-user chaos alone. It also guards against your own stale clones, laptops, or worktrees. Commenters noted that tools like Jujutsu make this the default because history rewrites are common there, but accidental deletion of unseen remote commits is not acceptable.
If your team rebases routinely, raw `--force` is an unnecessary footgun. `--force-with-lease` should be the team norm even for people who mostly work alone.
03 Git already includes a way to bootstrap `rerere` from history with `rerere-train`, which makes the feature more than a live-only convenience.
One commenter uses it to reconstruct prior merge knowledge, then rebase from an earlier merge-base while bisecting regressions on a large feature branch. That turns `rerere` into a debugging aid as well as a merge aid.
`rerere` is not just for future conflicts. You can mine past merges to make regression hunts and repeat rebases less painful.
04 Jujutsu came up as an implicit critique of Git’s conflict model, not just as a trend mention.
The attraction is that conflict resolution is treated as a first-class, per-change operation instead of a fragile, stateful rebase sequence that can be derailed mid-flight. The claim from people using it is that it tolerates inconsistent team workflows better than raw Git, which matters in real teams where discipline is uneven.
Some merge pain is not user error. Newer version control layers like Jujutsu are trying to fix assumptions in Git’s model, not just paper over them with more flags.
01 Frequent rebasing was challenged as aesthetics masquerading as rigor.
Rewriting history can leave intermediate commits broken or semantically meaningless, and almost nobody validates every rebased step. The useful artifact is the current tip, not a museum-quality commit graph. From this view, merge commits are a feature because they preserve what actually happened and avoid spending engineering effort on commit archaeology that no one will read.
A clean linear history is often less valuable than teams pretend. If rebasing adds cognitive load without improving delivery, just merge.
02 Setting `pull.
rebase=true` globally was treated as dangerous when people do not fully understand their local branch state. One commenter described coworkers getting dragged into confusing rebases just by running `git pull`, because support had silently installed the setting on new machines. The argument is straightforward: making rebases implicit turns a sharp tool into ambient behavior, which is exactly how teams end up in Git incidents they cannot explain.
Do not hide rebase behind defaults unless the team is trained for it. Invisible Git policy creates confusing failure modes.
03 Long-lived integration branches were defended as sometimes rational, especially for deep refactors, foundational API changes, or environments where testing is expensive and release cadence is not continuous.
The counterargument to trunk-only purity is that forcing everything through `main` can create repeated rework and shallow coordination. Another commenter replied that good architecture should create seams so you can avoid this, but even that response admitted it is hard and codebase-specific.
Not every team can flatten work into tiny trunk-friendly deltas. Sometimes branch complexity is a symptom of real technical coupling, not bad habits.