55

When I do git rebase branch1 in my branch1-local I get conflicts. I solve the conflict, do git add <conflicted-add> and then do git rebase --continue as git asks me to do. After that a new commit is applied. A new conflict shows up. But is the same conflict again in the same file. I do it again, git add, the git rebase --continue, and then it all repeats again until I repeat this for each commit being rebased on.

Why rebase is having me redo the same conflict resolution over and over again?

Rob Bednark
  • 25,981
  • 23
  • 80
  • 125
lurscher
  • 25,930
  • 29
  • 122
  • 185
  • 3
    I never used it, I barely read its documentation, but take a look at `git rerere`, AFAIK is used to "record" conflict resolutions and avoid repeating them. Take a look at http://stackoverflow.com/q/5519244/236871 for the usual gotchas of this feature. – KurzedMetal Dec 11 '12 at 18:09
  • Did you ever figure out why this happened? I had other people reporting the same thing and I would like to be able to reconstruct such a situation where I have to apply the *exact same conflict resolution* multiple times during a rebase. – Christoph Aug 15 '14 at 21:33
  • 4
    yes, the solution was to never *ever* use `rebase` again. `pull`, `merge` and resolve with `add` is all that you should ever need – lurscher Aug 19 '14 at 21:00
  • 2
    Hey man, don't hate on rebase. That stuff is golden. – henrebotha Apr 16 '15 at 08:49
  • 2
    Rebase basically sucks, because it changes history and creates commits that don’t correspond to any state that ever actually existed in development (and therefore were never tested). Dropping it is a good choice. :) – Marnen Laibow-Koser Mar 19 '19 at 04:18
  • squash and merge is clearly superior :-) – lurscher Mar 19 '19 at 16:45
  • @lurscher And `merge --no-ff` is superior to that, because it preserves history even better. Also, in general, use `git mergetool` to resolve conflicts. – Marnen Laibow-Koser Mar 26 '19 at 15:10
  • Does this answer your question? [Why does the same conflict reappear when I use git rebase?](https://stackoverflow.com/questions/31401754/why-does-the-same-conflict-reappear-when-i-use-git-rebase) – ggorlen Feb 11 '22 at 04:04

2 Answers2

14

What you want is git rerere which records conflict resolutions for you. The best introduction to this I have seen is now part of the Git Book, Tools chapter. In practice when you perform a rebase, you will end up stopping as before but you only have to check the merge conflict remains resolved then git add it and continue.

patthoyts
  • 32,320
  • 3
  • 62
  • 93
5

You should not be getting the same conflict over and over. Rerere will not help you here. It simply means that the codebase that you are trying to replay commits over is so different that each commit needs your help to adjust it. This is one of the reasons to favour merge over rebase. In my opinion, rebase should be used only if necessary and not part of your regular workflow. Rerere will help a lot more in a merge/reset type workflow. Here is my workflow that avoids rebasing: http://dymitruk.com/blog/2012/02/05/branch-per-feature/

One way to ease some of the pain is to use a smart merging program like Beyond Compare. It is syntax aware and will solve quite a few conflicts that Git will (rightfully) refuse to do for you. Many times, these tools, when invoked, won't even open their UI, solve the issue and allow your git mergetool command to continue on to the next conflict. Remember to set "trust mergetool exit code" to true.

Rob Bednark
  • 25,981
  • 23
  • 80
  • 125
Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
  • 4
    for the record, i personally favour merge (i've used it successfully in other projects with not so much as a glitch) but this new team wants to use rebase because it makes the merge tree look "tidier", and God knows that a tidier-looking tree beats fixing a conflict only once (specially when the lead that wants to look at tidy trees is not doing any conflict resolution himself) – lurscher Dec 11 '12 at 19:39
  • 2
    That's too bad. Usually people new to git that come from a SVN background where branching and merging was avoided like the plague want a neat history to look at. The power of git is the inspection of the graph (DAG) to see what was or wasn't merged yet into a branch of interest. Your best choice is to let them suffer through all the conflict resolutions and later suggest to try a workflow that doesn't rely on rebasing to keep things tidy. My workflow keeps things very organized. See if one or two of them will read my post. I should write another post addressing this. – Adam Dymitruk Dec 11 '12 at 19:48
  • i wish, but the conflict resolution suffering will be all on me. But i will try to make some advocacy for merge. thanks! – lurscher Dec 11 '12 at 19:51
  • Sorry to hear. Unfortunately, there is no easy answer for your question here and while it may take time, addressing the root cause of your issues will be the most helpful. – Adam Dymitruk Dec 11 '12 at 19:53
  • 7
    *Rebase should be used only if necessary and not part of your regular workflow.* -- This is plain wrong. From the horse's mouth: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html – Jonah Nov 05 '16 at 04:26
  • @Jonah `"So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN PRIVATE git tree."` So rebase can be considered not necessary and even NOT recommended (from horses mouth) for most peoples workflow.... assuming most people work on a team and do some sort of CI. – Ben George Apr 17 '17 at 04:48
  • 1
    @BenGeorge I don't read that at all from what linus says. *Everyone* no matter his or her workflow has occasion to clean work before publishing. And I *think* rebasing private work on top of a public branch seems consistent with his suggestion, although I'm not 100% clear on that point – Jonah Apr 17 '17 at 13:53
  • 1
    @Jonah Rebasing to fix some minor mistake in your private branch three commits ago is probably a very good idea (however, do rerun your test suite on each rewritten commit). Rebasing your entire branch onto the current upstream development is borderline (some people like it, but it means, you may be unwittingly changing the assumptions upon which your changes were made), rebasing something that's already public is usually a very bad idea (it's the direct route to confusion). In each case, only rebase if your reason for rebasing is more important than the possible problems resulting from it. – cmaster - reinstate monica Apr 09 '18 at 09:36
  • So what is the correct answer? In complex situations, use `git pull --no-ff`, in easy situations `git pull --rebase`. – Alex Mar 30 '23 at 06:58