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~!
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.
Also note that adding an empty file (e.g.
.gitkeep
) to the tree is considered by cherry-pick as an empty commit.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.
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.)