You ran git cherry-pick abc1234 to backport a fix, resolved a merge conflict in src/auth.ts, staged the file with git add, ran git cherry-pick --continue, and Git responded with The previous cherry-pick is now empty, possibly due to conflict resolution. If you wish to commit it anyway, use: git commit --allow-empty. Now the cherry-pick is suspended and you are not sure whether to allow the empty commit, skip it, or abort and start over. This situation is not a bug — it usually means the changes you were cherry-picking were already present on the target branch, and the conflict resolution produced a diff of zero net lines.
Common causes
Ordered by hit rate, highest first.
1. Target branch already contains equivalent changes
The commit you are cherry-picking modified lines that were already changed on the target branch, possibly by a previous cherry-pick, a merge, or a parallel fix. After resolving conflicts by accepting the target branch’s version, there is nothing new to commit.
How to spot it: Run git diff HEAD after staging — if it is empty, the working tree matches the current HEAD exactly. The “fix” is already there.
2. You accepted “ours” for every conflicting hunk
During conflict resolution you chose git checkout --ours -- src/auth.ts for every hunk. “Ours” means the current branch’s content, which HEAD already reflects. The result is no net change relative to HEAD.
How to spot it: git diff --cached shows no staged changes even though you have staged files.
3. Cherry-picking a revert of a revert (double-negation)
You are cherry-picking commit B, which reverted commit A, onto a branch that also reverted commit A via a different path. Both reversions produce the same content, so the cherry-pick has nothing to do.
How to spot it: git show abc1234 --stat shows the commit was a revert. Check whether an equivalent revert is already in the target branch’s history.
4. Whitespace-only differences resolved to nothing
The source commit changed only trailing spaces or indentation. The target branch had already applied an auto-formatting step, so after conflict resolution the effective diff is empty.
How to spot it: git diff --ignore-all-space HEAD is non-empty (whitespace is present) but git diff HEAD is empty.
5. Cherry-picking a range where some commits were already applied
git cherry-pick A..B picks multiple commits. Some in the middle were already backported individually, so their cherry-picks become empty mid-way through the range.
How to spot it: git log --oneline A..B lists 5 commits but git log --oneline target..HEAD only shows 3 of them already applied.
Shortest path to fix
Step 1: Confirm the commit is truly empty vs. accidentally empty
git diff --cached
git diff HEADIf both show no output, the cherry-pick is genuinely empty. If git diff HEAD has output but git diff --cached does not, you forgot to stage your conflict resolution.
Step 2: Stage any unstaged resolution files first (if the commit is not truly empty)
git add src/auth.ts
git cherry-pick --continue --no-editStep 3: If genuinely empty, decide whether to skip or allow-empty
Option A — skip (most common, recommended when changes already exist on target):
git cherry-pick --skipOption B — allow the empty commit (useful for audit trails or when commit metadata matters):
git commit --allow-empty -m "chore: cherry-pick abc1234 (no-op on this branch — changes already present)"
git cherry-pick --continue --no-editStep 4: Continue with the rest of a range pick
If you were doing a range cherry-pick and skipped one commit, continue with:
git cherry-pick --continue --no-editGit will move to the next commit in the range.
Step 5: Verify the final result
git log --oneline -5
git diff origin/target-branch -- src/auth.tsConfirm the intended fix is present on the target branch.
Prevention
- Before cherry-picking, check whether the commit is already in the target branch:
git branch --contains abc1234— if the target branch is listed, the cherry-pick will be empty. - Use
git log --cherry-pick --no-merges target..sourceto list only commits that are not already equivalent on the target branch. - When cherry-picking a range, inspect each commit first:
git log --oneline A..Band cross-reference withgit log --oneline target. - Prefer
--ff-onlymerges for hotfix branches to avoid divergent histories that make cherry-picks ambiguous. - In automated cherry-pick scripts, use
--skipby default and log the skipped SHAs so the team knows which commits were no-ops. - Document which commits have been cherry-picked across branches in a
BACKPORTS.mdor via pull-request labels so teammates do not duplicate the work.
FAQ
Q: I skipped the cherry-pick but the bug fix is not on the target branch. What happened?
A: Skipping means Git determined the changes were already present. Run git log --all --oneline --grep="your fix description" to find where the fix landed. It may be on a different branch or under a different commit message.
Q: Can I cherry-pick just one hunk from a commit, not the whole commit?
A: Yes. Use git cherry-pick -n abc1234 (the -n / --no-commit flag stages the changes without committing), then git reset HEAD src/auth.ts to unstage unwanted files, and finally git commit.
Q: git cherry-pick --continue fails with “no cherry-pick in progress.” What went wrong?
A: You already resolved the cherry-pick in the same session but did not notice. Check git status — if the working tree is clean and HEAD shows the cherry-picked commit, you are done.
Q: We cherry-pick hotfixes to a release branch regularly. Is there a better workflow?
A: Consider a “fix-forward” workflow where hotfixes land on the release branch first and are then merged up to main. This avoids cherry-pick empty issues because the diff direction is always forward.