You ran git cherry-pick abc1234 to backport a fix, resolved a merge conflict in src/auth.ts, staged it with git add, ran git cherry-pick --continue, and Git stopped 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
Otherwise, please use 'git cherry-pick --skip'This is not a bug, and your conflict resolution was probably correct. In almost every case it means the change you were picking is already present on the target branch, so after the three-way merge there is zero net diff to commit.
Fastest fix: if the change is genuinely already on this branch, run git cherry-pick --skip and move on. Only use git commit --allow-empty if you specifically want a no-op commit recorded (audit trail, keeping a 1:1 SHA mapping). Run the two diff checks in Step 1 first so you do not skip a commit you actually meant to keep.
Pick your fix in 10 seconds
Run both checks, then read the row that matches:
git diff HEAD | git diff --cached | What it means | Do this |
|---|---|---|---|
| empty | empty | Truly empty — change already on target | git cherry-pick --skip |
| empty | empty | Empty but you want it recorded | git commit --allow-empty -m "..." then git cherry-pick --continue --no-edit |
| has output | empty | You forgot to stage the resolution | git add <file> then git cherry-pick --continue --no-edit |
| any | any, but wrong content | You resolved with the wrong side | git cherry-pick --abort and redo (see cause 2) |
git diff HEAD compares the working tree to the last commit; git diff --cached compares the staging area to it. If both are empty, the working tree, the index, and HEAD are identical, so there is nothing to commit.
Common causes
Ordered by hit rate, highest first.
1. Target branch already contains equivalent changes
The commit you are picking touched lines that were already changed on the target branch, by an earlier cherry-pick, a merge, or a parallel fix. After the three-way merge resolves to the same content that is already there, the diff is empty.
How to spot it: git diff HEAD after staging is empty — the working tree already matches HEAD. Confirm with git branch --contains abc1234: if the target branch is listed, the change (by SHA) is already in its history.
2. You accepted “ours” for every conflicting hunk
During resolution you ran git checkout --ours -- src/auth.ts (or clicked “use current/HEAD” in a merge tool) for every hunk. In a cherry-pick, --ours is the branch you are picking onto (your HEAD), and --theirs is the commit you are picking in. Choosing “ours” everywhere keeps the target branch unchanged, so the picked change is discarded and the commit is empty.
How to spot it: git diff --cached shows no staged changes even though you staged files. If you actually wanted the incoming change, this is the one cause where you should not skip — abort and redo with --theirs.
3. The commit is a merge commit picked without -m
git cherry-pick <merge-sha> has no default parent to diff against, so it fails or produces an empty/garbled result.
How to spot it: git show --stat <sha> prints a Merge: abc1234 def5678 line. Re-pick with a mainline parent: git cherry-pick -m 1 <merge-sha> (parent 1 is usually the branch the merge landed on; parent 2 is the merged-in branch).
4. Cherry-picking a revert of a revert (double-negation)
You are picking commit B, which reverted commit A, onto a branch that also reverted commit A through a different path. Both reversions yield the same content, so there is nothing to do.
How to spot it: git show abc1234 --stat shows a revert; check whether an equivalent revert is already in the target branch’s history with git log --oneline --grep="Revert".
5. Whitespace-only diff that resolved to nothing
The source commit changed only trailing spaces or indentation, and the target branch already ran an auto-format pass, so the effective diff is empty.
How to spot it: git diff --ignore-all-space HEAD is empty (no real change) — confirming the picked commit carried no semantic change.
6. Some commits in a picked range were already applied
git cherry-pick A..B picks several commits; one in the middle was already backported individually, so it becomes empty partway through the range.
How to spot it: git log --oneline A..B lists, say, 5 commits, but git log --oneline target..HEAD shows 3 of them already present. This is the one case where the --empty flag helps (see Step 5).
Shortest path to fix
Step 1: Confirm truly empty vs. accidentally empty
git diff --cached
git diff HEADIf both are empty, the cherry-pick is genuinely empty. If git diff HEAD has output but git diff --cached does not, you forgot to stage your resolution — go to Step 2.
Step 2: Stage any unstaged resolution first
git add src/auth.ts
git cherry-pick --continue --no-edit--no-edit reuses the original commit message instead of opening an editor.
Step 3: If genuinely empty, skip or allow-empty
Option A — skip (recommended when the change is already on the target branch):
git cherry-pick --skipOption B — keep an empty commit (audit trail, or to preserve a 1:1 SHA mapping):
git commit --allow-empty -m "chore: cherry-pick abc1234 (no-op on this branch, change already present)"
git cherry-pick --continue --no-editDo not reach for git cherry-pick --continue --allow-empty here — a commit emptied by conflict resolution is treated by Git as “initially empty,” and only --skip, git commit --allow-empty, or --empty=keep will move it forward. The --empty=drop/--empty=stop settings do not apply to it (see Step 5).
Step 4: If you resolved with the wrong side (cause 2), redo it
git cherry-pick --abort
git cherry-pick abc1234
# on conflict, keep the INCOMING change:
git checkout --theirs -- src/auth.ts
git add src/auth.ts
git cherry-pick --continue --no-editStep 5: Range picks — drop the redundant ones automatically
For git cherry-pick A..B, commits that become empty because an earlier commit in the same range already applied them can be dropped automatically:
git cherry-pick --empty=drop A..BImportant limitation, verified against the official docs (as of June 2026): --empty=drop and --empty=stop only govern a commit that became empty due to a previous commit in the range. A commit that became empty due to conflict resolution (your situation) is treated as initially empty and still stops the pick — for that one you must use --skip per commit, or --empty=keep / --allow-empty if you want it kept. --keep-redundant-commits is a deprecated synonym for --empty=keep.
Step 6: Verify the final result
git status # should show "nothing to commit, working tree clean"
git log --oneline -5
git diff origin/target-branch -- src/auth.tsgit status should report no cherry-pick in progress, and the intended fix should be present on the branch.
Prevention
- Before picking, check if the commit is already there:
git branch --contains abc1234. If the target branch is listed, the pick will be empty. - List only commits not yet equivalent on the target with
git cherry -v target source— a leading-means the patch is already applied (will be empty),+means it is new. - For a range, inspect first:
git log --oneline A..Band cross-reference withgit log --oneline target. - Always pass
-m 1when picking a merge commit, and note it in the PR description. - In automated pick scripts, prefer
--empty=dropfor ranges and--skipfor the per-conflict case, and log the skipped SHAs so the team knows which commits were no-ops. - Track which commits have been backported across branches in a
BACKPORTS.mdfile or via PR labels so teammates do not duplicate the work.
FAQ
Q: Why doesn’t --empty=drop skip my conflict-emptied commit?
A: By design. The git docs state that --empty=drop/--empty=stop only handle a commit that became empty due to a previous commit. A commit emptied by your conflict resolution is treated as initially empty and still stops the pick — use git cherry-pick --skip (or --empty=keep / --allow-empty to keep it).
Q: I ran --skip but the bug fix is not on the target branch. What happened?
A: Skipping means Git found the change already equivalent on this branch. Find where it landed with git log --all --oneline --grep="your fix description" or git log --all --oneline -- src/auth.ts. It may be under a different commit message or on another branch.
Q: Can I cherry-pick just one hunk from a commit, not the whole commit?
A: Yes. Run git cherry-pick -n abc1234 (the -n / --no-commit flag stages without committing), then git restore --staged <unwanted-file> to drop files you do not want, and finally git commit.
Q: git cherry-pick --continue fails with “no cherry-pick in progress.” What went wrong?
A: The sequence already finished. Check git status — if the tree is clean and git log -1 shows your picked commit, you are done. If you used --skip or --abort it also clears the in-progress state.
Q: The empty commit was already pushed. How do I remove it?
A: If history rewriting is safe on that branch, git rebase -i HEAD~5 and delete the empty line (or git reset --hard HEAD~1 if it is the tip) and force-push with --force-with-lease. If the branch is shared and protected, leave it — an empty commit is harmless.
Q: We cherry-pick hotfixes to a release branch constantly. Is there a better workflow?
A: Consider “fix-forward”: land hotfixes on the release branch first, then merge up to main. The diff direction is always forward, which avoids most cherry-pick-empty situations.