Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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~!
                This happened with me when I accidentally tried to cherry-pick the wrong commit. Happens sometimes when using gitk.
– cst1992
                Nov 24, 2016 at 9:43
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.)
                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, 2011 at 1: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 8, 2014 at 0:50
                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, 2018 at 11:50
                This might happen if you revert a merge commit and the commit to be cherry-picked resides on the reverted branch.
– matt
                Apr 25, 2019 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 1, 2020 at 19:48
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.
                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, 2017 at 4: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, 2017 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, 2017 at 2:14
                Thanks I was really frustrated, this was the case....but hard check in a git log with 200+ commits
– AndrewRMillar
                Oct 26, 2022 at 12:53
                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 7, 2018 at 13:18
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.
                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, 2017 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
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>
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.