I'm trying to cherry-pick a commit from master and get it into the current production branch. However, when I execute git cherry-pick <SHA-hash>, I just get this message:

# On branch prod_20110801
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#   site/test-result/
 nothing added to commit but untracked files present (use "git add" to track)
 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'

Note: I've tried doing a reset and a reset --hard HEAD^, and neither seemed to change anything.

I'm confused as to why this isn't working for me.

Any insight, advice, or ideas on how to resolve this would be helpful~!

Jay Taylor
  • 13,185
  • 11
  • 60
  • 85
  • This happened with me when I accidentally tried to cherry-pick the wrong commit. Happens sometimes when using gitk. – cst1992 Nov 24 '16 at 09:43

6 Answers6


Git is resolving the cherry-pick as a no-op -- all of the changes introduced by that commit have been introduced by some commit on your current branch. (Or that's what Git thinks, anyway.) Verify that the commit you are cherry-picking hasn't already been merged somehow, as either a proper merge, rebase/cherry-pick, or piecemeal patch. (Use git show <commit-id> to see the diff.)

  • 158,093
  • 24
  • 286
  • 300
  • 24
    Thanks for your advice, it turns out the cherry-pick had already taken place and I all need to do was push it to github. – Jay Taylor Aug 16 '11 at 01:32
  • Right, I didn't realise it was checking the content of the files given the commit-id. I went looking for the commit-id in the log and couldn't find it. it turned out it was already merged in. – mparaz Jul 08 '14 at 00:50
  • 2
    Unfortunatelly, this is not the only reason of issue in question. I've got exactly same situation when I had commit, which reverts some earlier commit, and when I cherry-picked it on another branch, which history hadn't that changes being reverted (i.e. hadn't cherry-pick of that reverted commit). Of course, that's my fault. But in this case it's expected that git should fail with conflict status, instead of trying be too smart, which results in confused user. – Artem Pisarenko Oct 19 '18 at 11:50
  • 2
    This might happen if you revert a merge commit and the commit to be cherry-picked resides on the reverted branch. – matt Apr 25 '19 at 15:12
  • @HamDiou At the time I decided that I've lost enough time and did it manually. Checkout the commit, then move necessary changes using patch, kdiff, winmerge or whatever you like. – matt Dec 01 '20 at 19:48
  • `git show` might not help. In my case the file (that already included the cherry pick changes) was changed again (in the target branch!) in a later commit. It took me a while to realize that `git show` changes are not the differences of the cherry-pick. This is really hard to figure out, if other people made the changes and you have dozens of files. I wonder if there is a git command á "what would commit XY change, if applied to my current local version". In such cases the result of the command would be "nothing". – fishbone Jun 01 '22 at 09:25

In my case this was driving me nuts, as it was quite obvious that the specific commit I wanted to cherry pick had not been merged into my current branch.

It turns out someone had already cherry picked the commit a week prior. The changes, but not the specific SHA, were already in my current branch, and I had not noticed them.

Check the file(s) that you're attempting to cherry pick. If they already have the changes, a version of the commit has already been cherry picked or added in another manner. There is thus no need to cherry pick it again.

  • 33,281
  • 23
  • 160
  • 191
  • I'm pretty sure that the specific commit is *never* in your branch when it was brought in by a cherry pick, because the cherry pick will be a new hash, right? Or am I misunderstanding? – msouth May 21 '17 at 04:07
  • 1
    @msouth What I originally took away from other answers was "the commit was already merged", but I could see that it was *not* in my branch. You're right about cherry pick always being a new SHA though. – pkamb May 21 '17 at 18:55
  • Yeah, I was thinking "the specific commit, as identified by the hash", when I typed that. My language was imprecise. I am often looking back through the output of `git log --graph --pretty --decorate --oneline` to see whether a given SHA is in my branch or not. See my answer below about how you can also get mixed up based on thinking the commit message is indicative of the change--there's a situation where it isn't, and that's what led me to this question originally. One's brain tends to make those shortcuts and they can occasionally come back to bite you. – msouth May 24 '17 at 02:14
  • 1
    Thanks I was really frustrated, this was the case....but hard check in a git log with 200+ commits – AndrewRMillar Oct 26 '22 at 12:53

Also note that adding an empty file (e.g. .gitkeep) to the tree is considered by cherry-pick as an empty commit.

  • 381
  • 4
  • 7
  • In my case I had a revert commit (that was reverting an empty commit itself) before my cherry-pick try, so I guess anything empty-ish will probably cause this message to appear. – lidkxx Mar 07 '18 at 13:18

So, here's Yet Another Confusing Situation where this can arise: I had the following:

git log screenshot

I was trying to cherry pick 9a7b12e which is apparently nothing--it even tried to tell me on that line in the git log output that 4497428 was what I really wanted. (What I did was just looked for the commit message and grabbed the first hash I saw that had it). Anyway, just wanting to let people know that there's another way you can get tricked into trying to cherry pick a no op.

  • 832
  • 11
  • 21
  • 13
    Not very helpful for you to downvote without explanation--this is the exact reproduction of a problem I had that led to me finding this question on my search. If you have a recommendation for improving this, please tell me in comments instead of just downvoting. – msouth Jul 20 '17 at 19:03

I had a different variation on this theme and I never found a correct solution.

git checkout master
git rm .travis.yml
git commit -m "Travis build no longer needed"
git checkout <mybranch>
git cherry-pick <lastcommit>

This failed with the empty commit error. And I verified that the identical file was still present on the branch. In this case I just redid the commit on the branch, but it's frustrating.

git 2.27.0 on centos8

J Quinn
  • 319
  • 2
  • 8

I had same problem like you, Maybe this will help you, so make sure that you are not detached from HEAD and then try to cherry-pick them, so that means first do:

git checkout master

and then use:

git cherry-pick <your-commit-hash>
  • 329
  • 1
  • 8