Summary
The has_skip check in strict_cherry_pick_mappings_from_command (src/daemon.rs:2773) only inspects the final completing command's invoked_args for --skip. This correctly handles the case where cherry-pick --skip itself is the final command that auto-applies remaining commits. However, when a skip occurs mid-sequence and later commits also conflict, the final completing command is cherry-pick --continue — so has_skip is false.
Impact
With has_skip = false, min_count is set to source_commits.len(), and the loop only tries the full count. Since some commits were skipped, fewer new commits exist, resolve_linear_head_commit_chain_for_worktree fails, and the function returns an error — losing attribution for all cherry-picked commits in the sequence.
Repro scenario
git cherry-pick A B C # A conflicts
git cherry-pick --skip # skip A; B also conflicts
git cherry-pick --continue # complete with B and C applied (only 2 new commits, not 3)
At the --continue step: cmd.invoked_args contains --continue, not --skip, so has_skip = false, min_count = 3, but only 2 new commits exist → chain reconstruction fails.
Root cause
src/daemon.rs:2773:
let has_skip = cmd.invoked_args.iter().any(|arg| arg == "--skip");
let min_count = if has_skip { 1 } else { source_commits.len() };The heuristic only covers the final-command case. Skips that occur earlier in the sequence are not tracked.
Suggested fix
Track skipped commits in the daemon's cherry-pick pending state (alongside pending_cherry_pick_sources). When a --skip is observed, record it so that subsequent --continue commands know to widen the count range. This avoids relying on the final command's argv entirely.
Notes
Summary
The
has_skipcheck instrict_cherry_pick_mappings_from_command(src/daemon.rs:2773) only inspects the final completing command'sinvoked_argsfor--skip. This correctly handles the case wherecherry-pick --skipitself is the final command that auto-applies remaining commits. However, when a skip occurs mid-sequence and later commits also conflict, the final completing command ischerry-pick --continue— sohas_skipisfalse.Impact
With
has_skip = false,min_countis set tosource_commits.len(), and the loop only tries the full count. Since some commits were skipped, fewer new commits exist,resolve_linear_head_commit_chain_for_worktreefails, and the function returns an error — losing attribution for all cherry-picked commits in the sequence.Repro scenario
At the
--continuestep:cmd.invoked_argscontains--continue, not--skip, sohas_skip = false,min_count = 3, but only 2 new commits exist → chain reconstruction fails.Root cause
src/daemon.rs:2773:The heuristic only covers the final-command case. Skips that occur earlier in the sequence are not tracked.
Suggested fix
Track skipped commits in the daemon's cherry-pick pending state (alongside
pending_cherry_pick_sources). When a--skipis observed, record it so that subsequent--continuecommands know to widen the count range. This avoids relying on the final command's argv entirely.Notes
--skipat all, so this PR is strictly an improvement.ab0f820d) correctly handles the simpler--skip-as-final-command case and adds commit-message matching for non-front skips.