Using Git's rerere feature to escape recurring conflict hell • Hacker News Board

Re: Using Git's rerere feature to escape recurring conflict hell

#31

Post by kazinator » Mon, Jun 01, 2026, 5:06 PM UTC

mqus wrote: post #19

barbazoo wrote: post #9

Earlier quoted context omitted.

rerere is still useful here to handle merge conflicts after repeated rebases.

As someone who tried rerere and didn't see the point: How? Usually I rebase the same branch multiple times onto different, but successive commits of the master branch. But after I solved a bunch of conflicts of the first rebase, I shouldn't have the same conflicts again in a second one, since the rebased branch contains the merged conflict. Rebasing again could only turn up new conflicts (with newer, other commits on…

The point is that some organizations have a chaotic development process consisting of numerous similar branches. Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) and cut at a particular point in time, in order to isolate from the trunk.

What then happens is that when a bug is found that affects all branches, it must be cherry picked into all of them. If that cherry pick runs into conflicts, it is often the same conflicts, over and over again on each branch.

Of course, the fix is not to do that, but it's easier to say that than to get away from that kind of workflow once you are steeped in it up to the chin.

Re: Using Git's rerere feature to escape recurring conflict hell

#32

Post by cub-creature » Mon, Jun 01, 2026, 5:07 PM UTC

mamcx wrote: post #15

I use rerere when "forced" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS wor…

[dead]

Re: Using Git's rerere feature to escape recurring conflict hell

#33

Post by kazinator » Mon, Jun 01, 2026, 5:09 PM UTC

mamcx wrote: post #15

I use rerere when "forced" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS wor…

You should not be seeing the same conflicts over and over again in a situation in which you are on a single branch, just rebasing your unpublished commits.

You might get conflicts regularly, if people are touching the same area of the code that you are touching, but not the same ones.

rerere mainly comes into play when people have to backport commits into multiple similar branches, due to having a heavily forked git landscape.

Re: Using Git's rerere feature to escape recurring conflict hell

#34

Post by overtomanu » Mon, Jun 01, 2026, 5:21 PM UTC

dools wrote: post #5

I never get conflicts during a merge because I only ever merge in one direction. I get all my conflicts on branches because I rebase before merging. I started doing this years and years ago because I kept coming across these mysterious silent regressions with my team. I searched something like "git merge silent regressions" and came across this stackoverflow answer: https://stackoverflow.com/a/28510260 That completel…

I follow this approach and still get the same merge conflicts coming repeatedly while doing rebase.

Let's say in my feature branch in the first commit I change a line in a file which also gets changed in the main branch. Then I have done 3-4 change commits doing changes in the same file. Now while doing rebase, I will have to resolve this conflict 3–4 times again and again while git re-applies commit one by one, during rebase.

I think I get this sometimes even if rerere is enabled, I am doing rebase using Intellij though, so maybe rerere doesn't get used here somehow or maybe diff context changes, so rerere is not applicable.

Re: Using Git's rerere feature to escape recurring conflict hell

#35

Post by alexsmirnov » Mon, Jun 01, 2026, 5:39 PM UTC

overtomanu wrote: post #34

dools wrote: post #5

I never get conflicts during a merge because I only ever merge in one direction. I get all my conflicts on branches because I rebase before merging. I started doing this years and years ago because I kept coming across these mysterious silent regressions with my team. I searched something like "git merge silent regressions" and came across this stackoverflow answer: https://stackoverflow.com/a/28510260 That completel…

I follow this approach and still get the same merge conflicts coming repeatedly while doing rebase. Let's say in my feature branch in the first commit I change a line in a file which also gets changed in the main branch. Then I have done 3-4 change commits doing changes in the same file. Now while doing rebase, I will have to resolve this conflict 3–4 times again and again while git re-applies commit one by one, duri…

We usually squash feature branches before merge. To squash before rebase, I use git reset --soft $(git merge-base develop HEAD) && git commit && git rebase develop - you have to resolve final conflicts only

Re: Using Git's rerere feature to escape recurring conflict hell

#36

Post by barchar » Mon, Jun 01, 2026, 5:40 PM UTC

You can use the rerere-train script in the git repo to populate rerere from existing merges. I use this when something in a merge has regressed a big feature branch and I need to bisect. I can train rerere then rebase on the 2nd to latest merge-base, all while still doing no extra work if there isn't a regression.

Re: Using Git's rerere feature to escape recurring conflict hell

#37

Post by ruszki » Mon, Jun 01, 2026, 6:11 PM UTC

dools wrote: post #5

I never get conflicts during a merge because I only ever merge in one direction. I get all my conflicts on branches because I rebase before merging. I started doing this years and years ago because I kept coming across these mysterious silent regressions with my team. I searched something like "git merge silent regressions" and came across this stackoverflow answer: https://stackoverflow.com/a/28510260 That completel…

That’s a funny Stackoverflow answer. That explanation cannot cause code loss. At least not with plain Git.

What I would check is hooks, or any other customizations. Especially on Windows, data loss is absolutely possible with misconfigured hooks, but it has nothing to do with when a commit was made.

Re: Using Git's rerere feature to escape recurring conflict hell

#38

Post by Sohcahtoa82 » Mon, Jun 01, 2026, 7:01 PM UTC

kazinator wrote: post #31

mqus wrote: post #19

Earlier quoted context omitted.

As someone who tried rerere and didn't see the point: How? Usually I rebase the same branch multiple times onto different, but successive commits of the master branch. But after I solved a bunch of conflicts of the first rebase, I shouldn't have the same conflicts again in a second one, since the rebased branch contains the merged conflict. Rebasing again could only turn up new conflicts (with newer, other commits on…

The point is that some organizations have a chaotic development process consisting of numerous similar branches. Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever) and cut at a particular point in time, in order to isolate from the trunk. What then happens is that when a bug is found that affects all branches, it must be cherry picked int…

> Often there is a main trunk, and then branches that were made for particular product variants (like piece of hardware or whatever)

I worked at a place that did this.

The code was written in C, and I always thought the better solution would have been to use #define/#ifdef to flag certain blocks of code out of the compilation.

A branch for each product was a nightmare when there were 10+ products, some with multiple variations, each on its own branch. Backporting a bug fix meant cherry-picking into 20+ branches. What made it especially stupid was office politics from each product having its own PM, and then the PM for one of the products would decide the bug wasn't significant enough to spend the time doing the cherry-pick and testing. This happened too often when it came to security fixes when a PM didn't understand the issue.

Re: Using Git's rerere feature to escape recurring conflict hell

#39

Post by chuckadams » Mon, Jun 01, 2026, 8:04 PM UTC

mqus wrote: post #19

barbazoo wrote: post #9

Earlier quoted context omitted.

rerere is still useful here to handle merge conflicts after repeated rebases.

As someone who tried rerere and didn't see the point: How? Usually I rebase the same branch multiple times onto different, but successive commits of the master branch. But after I solved a bunch of conflicts of the first rebase, I shouldn't have the same conflicts again in a second one, since the rebased branch contains the merged conflict. Rebasing again could only turn up new conflicts (with newer, other commits on…

Happens all the time with long term dev branches, which tend to arise when the PR review process is such a bottleneck that work piles up. Anything cherry-picked out of those branches tends to run into similar conflicts. ReRe is pretty handy in those circumstances.

Re: Using Git's rerere feature to escape recurring conflict hell

#40

Post by saghm » Mon, Jun 01, 2026, 8:21 PM UTC

mamcx wrote: post #15

I use rerere when "forced" by team to use rebase. It not even work that much at the end (you can't control workflows outside yourself, that is why git ux is wrong: it desperately need total discipline). THEN, I move to jujutsu. Only has a few problems at start trying to use it as git, but after get the idea, all fine. BTW, this was with the same team and they never know, so JJ is in fact better: It survive OTHERS wor…

Agreed; making conflict resolution separate for each commit rather than requiring a stateful flow where interruptions need to abort the entire process is one of the many killer features of jj.