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

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

#11

Post by powersjcb » Mon, Jun 01, 2026, 2:54 PM UTC

adithyassekhar wrote: post #8

Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work. You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on…

Yeah, I absolutely never run into this problem.

Sometimes we will have a huge stack of changes one of us is "finished but not clear to merge".

either:

- We just swap ownership of the branches and eng 2 now commits directly in branch 1. We review the final content together and typically pull in a 3rd person to review our combined work. Eng 1 either pairs with eng 2 until its finished or starts on a task that is decoupled from those changes.

- We use an integration branch that gets threated like the temporary master branch until the feature is ready to merge.

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

#12

Post by 0123456789ABCDE » Mon, Jun 01, 2026, 2:56 PM UTC

0123456789ABCDE wrote: post #2

#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [pull] rebase = true [rebase] autoSquash = true autoStash = true [merge] # zdiff3 adds original text markers and removes matching lines from conflict regions # https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle conflictStyle = zdiff3 autoStash = true [push] autoSetupRemote…

addendum

these are changes tacked to my git config over time. they're the result of working in a constant crunch state, where smooth forward move was more import than the state of the git history you left behind. these options remove small annoying road bumps. you should avoid some of them if you're working under different constraints, or the commit process differs such that these options don't apply.

it all starts with `pull.rebase=true` it makes `git pull --rebase` the default behavior. then comes `rebase.autoStash`, which just wraps the rebase with a stash push/pop envelop. if rebase is not your thing, and you prefer merge, `merge.autoStash=true` works the same. finally `push.autoSetupRemote=true` will skip asking you to set a remote tracking branch, it makes `git push` default to `git push --set-upstream`.

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

#13

Post by Izkata » Mon, Jun 01, 2026, 3:04 PM UTC

0123456789ABCDE wrote: post #2

#~/.config/git/config [rerere] enabled = true autoUpdate = true while you're editing git config, consider these: [pull] rebase = true [rebase] autoSquash = true autoStash = true [merge] # zdiff3 adds original text markers and removes matching lines from conflict regions # https://git-scm.com/docs/git-config#Documentation/git-config.txt-mergeconflictStyle conflictStyle = zdiff3 autoStash = true [push] autoSetupRemote…

    [pull]
      rebase = true

Don't use this one unless you really know what you're doing. Multiple co-workers have gotten into really bizarre rebases because of it (like rebasing 70+ commits from master on top of their branch instead of the other way around), it seems to cause more problems than it solves.

The man page for "git pull" even has a warning about using this flag.

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

#14

Post by convolvatron » Mon, Jun 01, 2026, 3:09 PM UTC

adithyassekhar wrote: post #8

Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work. You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on…

when you're not just doing small patches (like Greenfield work), and you have multiple developers, it can be unreasonable and wasteful to do what you describe. say we're redoing the way memory management it being done, or changing a foundational api. A and B could go through master, but they'd have to redo a whole bunch of work. Or we could make an integration branch where A and B hash things out together and only push to master when their work is done. you can also see how this allows a lot more back and forth about the places where the designs interact rather than 'I got in master before you, so you get to eat a multi-day merge and I'm outta here'

this kind of interaction shows up more in a 'release' based model than CI environment, and one where the cost of testing is non-zero (because we're actually doing testing). I know that's not a very popular model, but not all software development is CI websites.

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

#15

Post by mamcx » Mon, Jun 01, 2026, 3:13 PM UTC

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 workflows.

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

#16

Post by skydhash » Mon, Jun 01, 2026, 3:26 PM UTC

convolvatron wrote: post #14

adithyassekhar wrote: post #8

Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work. You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on…

when you're not just doing small patches (like Greenfield work), and you have multiple developers, it can be unreasonable and wasteful to do what you describe. say we're redoing the way memory management it being done, or changing a foundational api. A and B could go through master, but they'd have to redo a whole bunch of work. Or we could make an integration branch where A and B hash things out together and only pu…

Those big refactoring should be discussed with the whole teams so everyone understands how they’re going to be affected. And rework like this should probably be hidden behind an abstraction (to do it gradually).

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

#17

Post by techwizrd » Mon, Jun 01, 2026, 3:36 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…

This is what I've been doing for years. It's remarkably stress-free!

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

#18

Post by convolvatron » Mon, Jun 01, 2026, 3:36 PM UTC

skydhash wrote: post #16

convolvatron wrote: post #14

Earlier quoted context omitted.

when you're not just doing small patches (like Greenfield work), and you have multiple developers, it can be unreasonable and wasteful to do what you describe. say we're redoing the way memory management it being done, or changing a foundational api. A and B could go through master, but they'd have to redo a whole bunch of work. Or we could make an integration branch where A and B hash things out together and only pu…

Those big refactoring should be discussed with the whole teams so everyone understands how they’re going to be affected. And rework like this should probably be hidden behind an abstraction (to do it gradually).

yes of course they should, that doesn't mean that integration branches aren't a good way to manage the tactical process. and often this kind of situation comes up when you're trying to do exactly that, introduce that abstraction that solves a whole bunch of issues, but requires cross-cutting changes.

the problem comes up the other way too. the person making the refactor can get stuck in a perpetual hell of constantly reapplying the changes to smaller deltas that are being committed daily to master.

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

#19

Post by mqus » Mon, Jun 01, 2026, 3:38 PM UTC

barbazoo wrote: post #9

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…

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 master branch).

How can I have the same conflict again for repeated rebases?

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

#20

Post by legorobot » Mon, Jun 01, 2026, 3:38 PM UTC

adithyassekhar wrote: post #8

Do people really merge left and right between branches? Tell me if I got this wrong, this is how I work. You got 4 devs. Each branched off from master. And we never merge from each other. Suppose 3 other people merged to master I pull it from master and fix only those conflicts. I’m not bringing your code into my branch unless it’s already finished and on master. If I need something you’re working on and it’s not on…

I thought this was how everyone worked.

I wish it were :)

This is the right way to do it. Whether using trunk-based development, git-flow, etc -- you're controlling the flow of merges in a particular direction.

However, I think the "larger planning issue" is harder to easily avoid when you have more devs, more changes, or the AI-boosted output we have today. If feature B requires feature A, and feature A isn't up-to-date with main, I could rebase feature A to main, then feature B to feature A. When feature A is merged and we're ready to PR feature B, I can rebase to main again then make my PR.