3

I run Xcode, which runs git operations automatically. This can cause some rebase -i operations to fail, if Xcode starts the operation faster than git does. That results in:

fatal: Unable to create '.git/index.lock': File exists.

If no other git process is currently running, this probably means a
git process crashed in this repository earlier. Make sure no other git
process is running and remove the file manually to continue.

The Xcode task completes before I can do anything, so index.lock is already gone and I should be ready to continue.

Okay, so I try git rebase --continue, since the other operation has finished by now, and index.lock should be gone. However, this quickly blows up, with an error message like:

The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git reset'
interactive rebase in progress; onto abcdef
Last commands done (X commands done):
   pick abcdef Something
   pick abcdef Something
Next commands to do (Y remaining commands):
   pick abcdef Something
   pick abcdef Something
You are currently rebasing branch 'foo' on 'abcdef'.

nothing to commit, working directory clean
Could not apply abcdef

At this point, I just give up, --abort, and start again. I lose the rebase strategy I made, and any conflicts that I resolved. What can I do to resume this process correctly, losing no data?

For the purposes of this question, "close Xcode before rebasing" isn't the answer I'm looking for. Assume that I've already forgotten to do that, and am in this broken state (also, Xcode takes forever to start up, and this only happens rarely).

JHZ
  • 998
  • 1
  • 7
  • 15

3 Answers3

3

Proceeding with git rebase --continue does not work because git failed before actually applying the patch in question. But you can do so manually:

git apply .git/rebase-apply/patch

Then, resolve conflicts if necessary and add the changed files to the index using git add and, finally, use git rebase --continue.

aspargillus
  • 46
  • 3
1

I am currently chasing the ghost producing the lock errors and came around your question. I have not found a way to continue the rebase, but you can enable rerere (reuse recorded resolutions) with git config --global rerere.enabled 1 globally for your user. This does neither fix the apparent race condition in git rebase nor allows you to continue a rebase but it will re-apply your conflict resolutions when retrying making it less painful.

stefanct
  • 1,772
  • 1
  • 23
  • 25
0

All of the changes introduced by that commit have been introduced by some commit on your current branch.

git cherry-pick not working

Community
  • 1
  • 1
Bryce Drew
  • 3,527
  • 1
  • 11
  • 24
  • When I re-run the rebase, it applies cleanly (or, at least, generates the same conflicts). – JHZ May 06 '16 at 20:22