125

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
  • 11,805
  • 11
  • 55
  • 83
  • 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

160

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.)

cdhowie
  • 133,716
  • 21
  • 261
  • 264
  • 18
    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
  • 1
    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
  • 1
    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
  • So how to resolve that situation @matt ? – HamzDiou Nov 30 '20 at 18:34
  • @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
12

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.

pkamb
  • 26,648
  • 20
  • 124
  • 157
  • 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
  • @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
6

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

Neamar
  • 265
  • 3
  • 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
3

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.

msouth
  • 716
  • 7
  • 21
  • 12
    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
1

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>
AriaN
  • 143
  • 6
0

One more possible reason of this error happening is the sequence of commits passed to git cherry-pick. You must select the first commit as the Start commit and then move forward in time.

I had the same problem, in my case commit history was as below,

   Commit Sequence   976e364---2b162b6---x...etc

I ran below which produced the same error/issue as the question,

git cherry-pick 2b162b6 976e364   //this is wrong commit sequence

underlying issue above case is the commit sequence.

git cherry-pick 976e364 2b162b6   //this is correct commit sequence

In the git official documentation it states as

Note: Commit Sequence matters indeed.

# Find the range of commits you wish to re-add to your branch.
# then use cherry-pick to add them back to the branch
git cherry-pick start..end

# If you wish to include the start commit as well add the ^
# This will result in a cherry-pick of the start commit included as well 
git cherry-pick start^..end
mahen3d
  • 5,246
  • 12
  • 46
  • 94