15
$ git cherry-pick 5de83068
error: Your local changes to the following files would be overwritten by merge:
        Components/ApplicationEnums/Application.cs
Please, commit your changes or stash them before you can merge.
Aborting

$ git status
# On branch master
nothing to commit (working directory clean)

UPDATE Sorry, I switched to another branch, and switched back again, and can't reproduce this anymore :(

Benjol
  • 63,995
  • 54
  • 186
  • 268
  • Sounds like you managed to get your index out of sync somehow. – Cascabel Nov 24 '10 at 15:38
  • @Jefromi, so switching branches mended that. What is the 'official' way of re-syncing the index? And do you have any idea how I could have got into that state? (if you care to answer that, I'll update my question accordingly) – Benjol Nov 25 '10 at 05:54
  • I'm really not sure how it'd have happened. A `reset --soft` might verify things, and a `reset` (`--mixed`, the default) would update the index from the current commit. – Cascabel Nov 25 '10 at 13:51

6 Answers6

11

I had this issue. Error was - error: Your local changes would be overwritten by cherry-pick. hint: Commit your changes or stash them to proceed. fatal: cherry-pick failed The reason for me was I had a file in staging area that I don't wants to commit. I moved that file from staging area and tried to chery-pick again and that was a success.

Nimmi Mathew
  • 283
  • 2
  • 10
2

I'm not quite sure whats the problem but you can reset your working copy with the follwing statement:

git reset --hard origin/master
scheffield
  • 6,618
  • 2
  • 30
  • 31
  • Thanks, but I don't think I have an origin/master, this is a standalone repository. – Benjol Nov 24 '10 at 07:20
  • OK, so can you provide us your .git/config? – scheffield Nov 24 '10 at 07:28
  • 2
    There's no reason to reset to origin's master. You really don't want to move the branch - it's already where you want it, there's just something funky in index/work tree. Resetting to HEAD (`git reset`, or *maybe* `git reset --hard`) is plenty. – Cascabel Nov 25 '10 at 14:22
  • 3
    This is a slightly dangerous suggestion, not everyone is working on master or wants to reset to it. – Stuart Axon Apr 02 '20 at 17:14
  • 12+ years later and this was the solution I needed. Thanks. (I reset to a different branch than master though.) – xelf Feb 27 '23 at 19:33
2

The patch from the cherry-pick does not align in terms of the seams of where the changes would be applied. Do a --no-commit to see what happens.

Adam Dymitruk
  • 124,556
  • 26
  • 146
  • 141
1

In my case, I got the error while running

git cherry-pick -x <commit1> <commit2> <commit3>

Running the cherry-picks independently works:

echo <commit1> <commit2> <commit3> | xargs -n 1 git cherry-pick -x
Sebastian Wagner
  • 2,308
  • 2
  • 25
  • 32
0

I've had this problem when using git on a virtual machine, where the working copy was a VMware shared folder. I don't really know what the solution is. In my case I was able to get git to move away the changes it thought existed via git stash (upon inspection appeared to be completely empty); after the changes had been moved away I could cherry-pick on top of the now clean working copy. (After this, I just deleted the stash.)

mjs
  • 63,493
  • 27
  • 91
  • 122
0

I came here from googling about that weird message and I'd like to put my two cents.

For what is worth, my scenario is as following:

  • real code resides in a Virtual Machine
  • Mac OS connects to it via samba network sharing
  • Visual Studio Code is running on my Mac
  • git is running from within VS Code

I did experienced what OP wrote and I resolved by doing... nothing but wait! :)

Maybe there was a cache or a network problem, who knows.

LucaM
  • 799
  • 1
  • 10
  • 21