I have a git branch (called v4), that was made from master just yesterday. There were a couple of changes to master, that I want to get into v4. So, in v4, I tried to do a rebase from master, and one file keeps screwing things up: a one-line text file, that contains the version number. This file is app/views/common/version.txt, which before rebasing contains this text:
v1.4-alpha-02
Here’s what I’m doing:
> git rebase master
First, rewinding head to replay your work on top of it...
Applying: new version, new branch
error: patch failed: app/views/common/version.txt:1
error: app/views/common/version.txt: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging app/views/common/version.txt
CONFLICT (content): Merge conflict in app/views/common/version.txt
Failed to merge in the changes.
Patch failed at 0001 new version, new branch
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
The version.txt now looks like this:
<<<<<<< HEAD:app/views/common/version.txt
v1.4-alpha-02
=======
v1.4-alpha-01
>>>>>>> new version, new branch:app/views/common/version.txt
So, I tidy it up and it looks like this now:
v1.4-alpha-02
and then I tried to carry on: at first I try a commit:
> git commit -a -m "merged"
# Not currently on any branch.
nothing to commit (working directory clean)
No luck there. So, I was trying to add the file:
git add app/views/common/version.txt
No response. No news is good news, I guess. So, I try to continue:
> git rebase --continue
Applying: new version, new branch
No changes - did you forget to use 'git add'?
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
It’s at this point, after going round and round with this, that I’m banging my head off the desk.
What’s going on here? What am I doing wrong? Can anyone set me straight?
EDIT – for unutbu
I changed the file as you suggested and get the same error:
> git rebase master
First, rewinding head to replay your work on top of it...
Applying: new version, new branch
error: patch failed: app/views/common/version.txt:1
error: app/views/common/version.txt: patch does not apply
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging app/views/common/version.txt
CONFLICT (content): Merge conflict in app/views/common/version.txt
Failed to merge in the changes.
Patch failed at 0001 new version, new branch
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".
I encountered a similar problem with a rebase. My problem was caused because one of my commit only changed a file, and when resolving, I discarded the change introduced in this commit. I was able to solve my problem by skipping the corresponding commit (
git rebase --skip).You can reproduce this problem in a test repository. First create the repository.
Then commit the original content of
version.txtin master.Create the
v4branch and change the content ofversion.txt.Go back to
masterand change the content ofversion.txtso that there will be a conflit during the rebase.Switch back to
v4branch and try to rebase. It fails with a conflit inversion.txtas planned.We resolve the conflict by selecting the
mastercontent ofversion.txt. We add the file and try to continue our rebase.It fails ! Let’s see what changes
gitthink there is in our repository.Ah ah, there is no change. If you read in detail the previous error message,
gitinformed us of this and recommended to usegit rebase --skip. He told us “If there is nothing left to stage, chances are that something else already introduced the same changes; you might want to skip this patch.” So we just skip the commit and the rebase succeed.Word of caution: Please note that
git rebase --skipwill completely drop the commit thatgittried to rebase. In our case, this should be okay sincegitis complaining this is an empty commit. If you think you’ve lost changes once the rebase is complete, you can usegit reflogto get the commit id of your repository before the rebase, and usegit reset --hardto get your depot back in that state (this is another destructive operation).