1

This question is not a duplicate.

I did a git rebase origin<branch_name> on my branch. I resolved the conflicts and did git rebase --continue to apply the next commit. As I proceeded, git said:

No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

Resolve all conflicts manually, mark them as resolved with
"git add/rm <conflicted_files>", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase --abort".

This time I did:

git rebase --skip

Now in one of the files, I see the following:

<<<<<<< HEAD
=======
<<<<<<< HEAD
<<<<<<< HEAD
>>>>>>> <commit_message>

Note the opening a new conflict marker block before the earlier conflict marker got closed. I am not sure what is happening. I aborted the rebase and followed the steps and again the same issue.

I understand the following pattern but not the above pattern:

<<<<<<< HEAD
=======
>>>>>>> <commit_message>

More context: I am branch on B. I was doing git rebase A. Where A is another feature branch. History of branch A is:

c1-c2-c3 (branch A)

History of branch B before rebase with A is:

   c4-c5-c6 (branch B)

In the middle of rebase (git checkout B; git rebase origin/A), I see the following history on branch B

c1-c2-c3-c1  (branch B - while incomplete rebase with A)

Note that the commit c1 is applied again but with a different Hash Id

john456
  • 75
  • 6
  • 1
    That means you had a merge conflict, git was trying to indicate the "before" and "after" so you could resolve what the merge should result it for those lines. – Cory Kramer Aug 05 '20 at 21:03
  • @CoryKramer I have edited the question – john456 Aug 05 '20 at 21:09
  • @CoryKramer what it means when "<<<<<<< HEAD" appears in immediate lines. There was no code in-between – john456 Aug 05 '20 at 21:10
  • @CoryKramer do you still feel the question is duplicate? I understand the conflict markers. But what I am seeing is so irregular. – john456 Aug 05 '20 at 21:23
  • This is a nested conflict. The default merge algorithm, `merge-recursive`, can perform a merge to create the merge base, and when that has conflicts, this occurs. `rebase` can use `merge` under the hood, so it can trigger this case. – bk2204 Aug 06 '20 at 01:23
  • @bk2204 Thanks for the reply. Is there a way I can solve this issue? One thing I am 100% sure about is that there were no unresolved conflicts before this nested conflicts appeared. I did this twice and both the times I see the same issue. – john456 Aug 06 '20 at 02:57

0 Answers0