Can't resolve rebase conflict

Question

foo:/opt/bar$ git status
# On branch develop
nothing to commit (working directory clean)

foo:/opt/bar$ git pull --rebase origin develop
From ssh://xxx/yyy
* branch develop -> FETCH_HEAD
First, rewinding head to replay your work on top of it...
Applying: Subscription logging added.
Using index info to reconstruct a base tree...
<stdin>:120: trailing whitespace.
* @return integer
<stdin>:143: trailing whitespace.
* @return integer
<stdin>:166: trailing whitespace.
* @return integer
<stdin>:189: trailing whitespace.
* @return integer
<stdin>:212: trailing whitespace.
* @return integer
warning: squelched 3 whitespace errors
warning: 8 lines add whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging app/config/config.yml
CONFLICT (content): Merge conflict in app/config/config.yml
Failed to merge in the changes.
Patch failed at 0001 Subscription logging added.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

foo:/opt/bar$ git status
# Not currently on any branch.
# Unmerged paths:
# (use "git reset HEAD <file>..." to unstage)
# (use "git add/rm <file>..." as appropriate to mark resolution)
#
# both modified: app/config/config.yml
#
no changes added to commit (use "git add" and/or "git commit -a")

foo:/opt/bar$ git add -A

foo:/opt/bar$ git status
# Not currently on any branch.
nothing to commit (working directory clean)

foo:/opt/bar$ git rebase --continue
Applying: Subscription logging added.
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.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

foo:/opt/bar$ git add -A

foo:/opt/bar$ git status
# Not currently on any branch.
nothing to commit (working directory clean)

foo:/opt/bar$ git rebase --continue
Applying: Subscription logging added.
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.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".

foo:/opt/bar$

Answer 1

You are on the right path. You just need to use skip the commit on which you have problems:

git rebase --skip

You have fixed the conflict, but this has resulted in no changes compared to the previous commit. In this case you cannot just git rebase --continue, because you are telling Git to create an empty commit, which is not allowed.

If you have conflicts for any other commits you should still use git rebase --continue.

The --skip option is also useful when you don't want to include certain commit at all in the newly produced history.

Answer 2

git rebase --skip is indeed the right solution, except there is a case where it would get stuck and wouldn't be able to go on with the current rebase.

Git 2.0.2 (July 2014) has fixed that bug: see commit 95104c7 by brian m. carlson (bk2204):

rebase--merge: fix --skip with two conflicts in a row

If git rebase --merge encountered a conflict, --skip would not work if the next commit also conflicted.
The msgnum file would never be updated with the new patch number, so no patch would actually be skipped, resulting in an inescapable loop.

Update the msgnum file's value as the first thing in call_merge.
This also avoids an "Already applied" message when skipping a commit.
There is no visible change for the other contexts in which call_merge is invoked, as the msgnum file's value remains unchanged in those situations.

Answer 3

This post helped me fix a similar (if not the same) problem, but the OP didn't even ask a question. I understand that it is clear from the commands what was going on, but may not be so obvious to someone less knowledgable (I almost just didn't bother looking at it) so:

When you need to rebase your remote branch, call it myBranch, (because lets say you had pushed a few days ago, and other developers beat you to it and merged new changes since then) before you can merge to master (or whatever target branch), you have to rebase. Gitlab will say:

"Not possible to fast-forward merge. You must first rebase locally."

Usually just need to:

git checkout master

git pull

git checkout myBranch

git rebase master

<fix issues, then git add .>

git rebase --continue

BUT in this special case, git will tell you that you have no changes, and ask if you forgot to "git add". Because you're not making any new commits, changes you made in myBranch already have been committed, just elsewhere and you wish to copy over your old commits, this is where git rebase --skip is appropriate.

Hope that helps someone like me if they come across this question and are desperate enough to scroll to the bottom!

Answer 4

Git is saying the conflict you resolved is changed in future commits again & you have no changes at the current situation. Now git does not allow you to continue to rebase as it can't create an empty commit.

If you do git rebase --skip now, then in the next commit where that file is changed will show the same conflict again & again.

To avoid this you can manually commit using: git commit --allow-empty & then do a git rebase --skip.

This will prevent having to resolve the same conflict again & again.