Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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".
                @MaxWilliams, I think you (like me) have misinterpreted  @unutbu's advice: 1) first you run git rebase master and let it fail; 2) then you edit version.txt and make it as it should look at that point, and save the edit; 3) then you git add .../version.txt; 4) then you do git rebase --continue (not 'commit')! If rebase --continue succeeds here, it is already committed (no need for git commit here!) - so all that is left to do is git push (if you use a remote repo). Hope this helps, if I got it right :) - cheers!
– sdaau
                Apr 23, 2013 at 18:18
                @MaxWilliams, did you ever get an answer for this: ruby-forum.com/topic/187288 ( I will promptly delete this after a reply if someone else doesn't get there first!!)
– atw
                Feb 25, 2016 at 12:21
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.
$ mkdir failing-merge
$ cd failing-merge
$ git init
Initialized empty Git repository in $HOME/failing-merge/.git/
Then commit the original content of version.txt in master.
$ echo v1.4-alpha-02 > version.txt
$ git add version.txt
$ git commit -m initial
[master (root-commit) 2eef0a5] initial
 1 files changed, 1 insertions(+), 0 deletions(-)
 create mode 100644 version.txt
Create the v4 branch and change the content of version.txt.
$ git checkout -b v4
Switched to a new branch 'v4'
$ echo v1.4-alpha-03 > version.txt
$ git add version.txt
$ git commit -m v4
[v4 1ef8c9b] v4
 1 files changed, 1 insertions(+), 1 deletions(-)
Go back to master and change the content of version.txt so that there will be a conflit during the rebase.
$ git checkout master
Switched to branch 'master'
$ echo v1.4-alpha-04 > version.txt
$ git add version.txt
$ git commit -m master
[master 7313eb3] master
 1 files changed, 1 insertions(+), 1 deletions(-)
Switch back to v4 branch and try to rebase. It fails with a conflit in version.txt as planned.
$ git checkout v4
Switched to branch 'v4'
$ git rebase master
First, rewinding head to replay your work on top of it...
Applying: v4
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging version.txt
CONFLICT (content): Merge conflict in version.txt
Recorded preimage for 'version.txt'
Failed to merge in the changes.
Patch failed at 0001 v4
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".
$ cat version.txt
v1.4-alpha-04
=======
v1.4-alpha-03
We resolve the conflict by selecting the master content of version.txt. We add the file and try to continue our rebase.
$ echo v1.4-alpha-04 > version.txt
$ git add version.txt
$ git rebase --continue 
Applying: v4
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 restore the original branch and stop rebasing run "git rebase --abort".
It fails ! Let's see what changes git think there is in our repository.
$ git status
# Not currently on any branch.
nothing to commit (working directory clean)
Ah ah, there is no change. If you read in detail the previous error message, git informed us of this and recommended to use git 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.
$ git rebase --skip
HEAD is now at 7313eb3 master
Word of caution: Please note that git rebase --skip will completely drop the commit that git tried to rebase. In our case, this should be okay since git is complaining this is an empty commit. If you think you've lost changes once the rebase is complete, you can use git reflog to get the commit id of your repository before the rebase, and use git reset --hard to get your depot back in that state (this is another destructive operation).
                Thanks for taking the time to write that lengthy explanation Sylvain!  That does make it clearer.  I think i was always just nervous of skipping a patch as it felt like work could get lost: ie that the patch involved all the files affected by the rebase, rather than just the one with the conflict.  Is a patch just a single merge on a single file then?
– Max Williams
                Feb 1, 2011 at 9:25
                No, a patch contains all the difference on all the files modified in a single commit. But when using git rebase --skip, you only skip a single commit. I generally issue a git status before skipping a commit to see if I am in this situation.
– Sylvain Defresne
                Feb 1, 2011 at 13:41
                I just wanted to echo Max in saying thanks for taking the time to write up a great explanation—I finally understand why this is happening. I'm also no longer scared of rebase --skip :).
– Ben Dolman
                Dec 13, 2011 at 18:25
                Warning - if you have several changes in one commit, you may lose work doing git rebase --skip. I just did
– Chrissy H
                Feb 7, 2013 at 17:02
                @ChrissyH Unless you did a git reflog purge or git reflog delete you can still get your changes back by using git reflog. Try to checkout the different commit that are referenced there, one of them should be the state of your tree before you started the whole git rebase.
– Sylvain Defresne
                Feb 7, 2013 at 18:46
  
Turns out that because there is no
  change from the patch git suspects
  something has gone wrong. Git expects
  a patch to have been applied, but the
  file has remained unchanged.
  
The error message is not very
  intuitive, but it does contain the
  answer. We just need to tell rebase to
  skip this patch. It's also not
  necessary to fix the conflict markers
  in the file. You will end up with the
  file version from the branch you are
  rebasing on.
$ git rebase --skip
                After I used git mergetool and fixed the changes, then added them and committed them, I simply entered <code>git rebase --skip</code> while 'Not currently in any branch.' And everything was fixed. Thanks!
– geerlingguy
                Jan 24, 2012 at 16:49
                Actually, I think it was a combination of continually running git mergetool, then git rebase --continue, then git mergetool, etc. that finally fixed my situation.
– geerlingguy
                Jan 25, 2012 at 23:36
That error message is a result of your git commit -a -m "merged". If you just fix up the file, then run git add <file>, and git rebase --continue, it should work fine. git rebase --continue is trying to do a commit, but finding that there are no pending changes to commit (because you committed them already).
                This seems a good deal more reasonable than doing a skip, at least in the general case.  I'm surprised it's not listed as the best answer.
– EmeraldD.
                Mar 28, 2014 at 14:44
                @EmeraldD., Doesn't work. Fixing the file and running git add <file> won't solve the problem. git rebase --continue still reports No changes - did you forget to use 'git add'?
– Pacerier
                Oct 16, 2015 at 10:35
At this point in the rebase, remember that you are resolving merge conflicts to show the progression of the non-master branch.
So, in rebasing from
      A---B---C topic
D---E---F---G master
              A*--B*--C* topic
D---E---F---G master
the conflict you are resolving is in how to create A* on the topic branch.
So after doing git rebase --abort, the commands should be
git checkout topic
git rebase master
< make edits to resolve conflicts >
git add .
git rebase --continue
The behavior you're seeing is not what I would expect from a typical rebase with just this conflict. Consider using a separate branch to do this rebase (especially if you've already pushed the commits remotely that you're fast-forwarding). Also, git mergetool can be helpful for resolving conflicts and remembering to issue a git add.
In this minimal example, the rebase works as expected. Can you provide an example that shows the behavior you're seeing?
#!/bin/bash
cd /tmp
mkdir rebasetest
cd rebasetest
git init
echo 'v1.0' > version.txt
git add version.txt
git commit -m 'initial commit'
git checkout -b v4
echo 'v1.4-alpha-01' > version.txt
git add version.txt
git commit -m 'created v4'
git checkout master
git merge v4
echo 'v1.4-alpha-01-rc1' > version.txt
git add version.txt
git commit -m 'upped version on master to v1.4-alpha-01-rc1'
git checkout v4
echo 'v1.4-alpha-02' > version.txt
git add version.txt
git commit -m 'starting work on alpha-02'
git rebase master
echo 'v1.4-alpha-02' > version.txt
git add version.txt
git rebase --continue
Before starting the rebase, make sure you aren't in the middle of a rebase or am. Do: rm -rf .git/rebase-apply
if you use Bash, enhance your bash prompt so it always presents this information automatically
One bit you mentioned I didn't understand: "and then try to carry on: at first i try a commit:"... why commit? In the middle of a rebase I think you should only "git add" after you tidy up or "git rm" to toss changes or confirm a file deletion. Maybe that messed something up?
try a merge instead of a rebase
try some of Ethan Rowe's ideas
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.