3

I heard people saying that they had to fix the exact same conflict multiple times during a rebase. That means, fix the conflict, run git rebase --continue, get the same conflict again, fix it, run git rebase --continue and so on and so on. I know that there is git rerere that can record the conflict resolution.

My question is a bit unusual (I still pray for it not to get closed though!). I'm preparing a workshop on Git and I have trouble to come up with a scenario that causes the described behavior.

The git rerere documentation lists a different use cases where you test a merge, then reset it but want to remember the conflict resolution for the real merge at a later time. That's not what I'm after.

I'm really trying to come up with the scenario described above. Is it a myth? I think I actually observed it myself long time ago but I'm not 100 % sure.

Does anyone know what would cause that behavior?

Christoph
  • 26,519
  • 28
  • 95
  • 133
  • Did you ever figure out what causes this? Conceptually since a rebase just cherry-picks one at a time, I don't see how identical conflicts could ever happen. Maybe it's possible that when people say "repeated conflicts" they don't mean _identical_ ones but rather just _similar_ ones (i.e. maybe indentation changed or lines moved upward). This also accords with what I've read where `git rerere` rarely kicks into action on rebases. – 1110101001 Apr 11 '21 at 01:41

1 Answers1

0

A rebase reapplies commits on top of a branch.

Logically, if the first commit modify the same line than the commit on top of which it applied, that would generate a merge conflict.

So a scenario is where:

  • you update a master branch with a hotfix
  • while you have changed that same file in your dev branch with a new implementation

When rebasing dev on top of master, you should see merge conflict that you could record.
Add a second hotfix on a different file, and a second rebase: the first merge conflict should now automatically be resolved.

I wonder if it's a myth but I had people reporting that they had to apply the exact same conflict resolution for every commit that gets applied during the rebase

That can happen if the branch on top of which you rebase... has been force pushed.

And (you know that already, but I include it for others):
git rerere wouldn't help you in the case where the conflict resolution is to skip a particular commit being rebased.

As mentioned in this thread (and by yourself in this tweet):

That is like saying "my hammer is very helpful when I want to hit nails, but sometimes I wish it helped me with screws".

The only thing "rerere" does is to remember the shape of the conflicted state and desired resolution per file.
It does not tell "rebase" what to do next (you do, via "git add -u" followed by "git rebase --continue").

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Yes, I know. That's why I'm having trouble to come up with the described situation. I wonder if it's a myth but I had people reporting that they had to apply *the exact same conflict resolution* for every commit that gets applied during the rebase. – Christoph Aug 15 '14 at 21:03
  • Take a look at this question. http://stackoverflow.com/questions/13825079/git-rebase-why-i-have-to-resolve-the-same-conflict-over-and-over/13827166#13827166 This guy seems to have exactly that problem but answers just recommend to use `git rerere` but no hint what would causing this. – Christoph Aug 15 '14 at 21:07
  • I will take a look, tomorrow. Night time. – VonC Aug 15 '14 at 21:08
  • sure! Thanks for looking into it! – Christoph Aug 15 '14 at 21:09
  • @Christoph "apply the exact same conflict resolution for every commit that gets applied during the rebase": that should be the case when you rebase on top of a force pushed branch. I have added some other thoughts in my edited answer. – VonC Aug 16 '14 at 10:23
  • Thanks. I'll try to reproduce that probably later tonight or the next night and post an update here. – Christoph Aug 16 '14 at 21:28
  • Mmh, I tried to reproduce it but even if I rebase on top of a branch that was rebased itself and force pushed I fail to come into the described situation. I tried to rebase on a branch where I changed the root commit so that there was no common ancestor at all and also on a branch where the history was just partly changed but still I couldn't put myself as much into trouble as the laid out scenario suggests. Actually a good thing but I really wish to demystify this observation. – Christoph Aug 18 '14 at 22:18