git cherry-pick not working

Question

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~!

Solution 1

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

Solution 2

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.

Solution 3

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

Solution 4

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

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.

Solution 5

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

View more solutions

Comments

[cst1992]

This happened with me when I accidentally tried to cherry-pick the wrong commit. Happens sometimes when using gitk.

[Jay Taylor]

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.

[mparaz]

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.

[msouth]

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?

[pkamb]

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

[msouth]

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]

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.

[lidkxx]

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.

[Artem Pisarenko]

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.

[matt]

This might happen if you revert a merge commit and the commit to be cherry-picked resides on the reverted branch.

[matt]

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

[fishbone]

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