Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using Git's rerere feature to escape recurring conflict hell

gist.github.com

Post reply on HN
Print view View original

1–10 of 58 posts

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

#2

Post by 0123456789ABCDE » 

  #~/.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 = true
      default = simple

  [init]
      defaultBranch = main

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

#5

Post by dools »

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 completely fixed the problem. Now I only ever get conflicts on my feature branches. The rule is always: rebase away from main, and merge towards main. All conflicts are then on your branches, never on main, and always from rebase, never from merge. Then I set the pull behaviour to rebase, too.

I've never had a silent regression since, and never had a problematic conflict scenario.

I did recently learn about ORIG_HEAD though which was very cool, because I had accidentally rebased to main instead of to a dev branch from which I had created a bunch of worktrees, then when I merged back to the dev branch all hell broke loose, and I learned that I could revert a merge by checking out ORIG_HEAD:

https://icinga.com/blog/undo-git-reset-hard/

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

#6

Post by ubercore »

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've never even seen someone suggest a rebase master onto feature workflow! TIL.

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

#7

Post by dools »

ubercore wrote: post #6
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've never even seen someone suggest a rebase master onto feature workflow! TIL.

I think the terminology would be the other way around, like you're rebasing the feature onto the main:

git checkout feature

git rebase main

git checkout main

git merge feature

that way you get all your conflicts on the feature branch during rebase and your merge is always clean.

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

#8

Post by adithyassekhar »

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 master when I need it, it’s a much larger planning issue.

If you have multiple environments before a stable master, do it only in one direction: feature > dev > staging > master. Don’t merge branches straight into staging or master.

I thought this was how everyone worked.

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

#9

Post by barbazoo »

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.

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

#10

Post by barbazoo »

ubercore wrote: post #6
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've never even seen someone suggest a rebase master onto feature workflow! TIL.

> I get all my conflicts on branches because I rebase before merging

Pretty sure it's the other way around. You're on the branch and rebase it atop current master. If you merge after that, you won't have merge conflicts.

Post reply on HN