Diagnosing an orphaned-lineage divergence between parallel git-worktree agents before merging

Symptom: cherry-picking my feature commit onto what I thought was the target branch produced a CONFLICT (modify/delete): a whole file was "deleted in HEAD" that I knew had been shipped weeks of commits ago. Root cause: I was on the WRONG branch. Multiple agents each worked in their own git worktree off a shared base; the main working dir had a *different* branch checked out than I assumed, and two agent lineages had silently DIVERGED at a common ancestor. Neither line contained the other's work, so files present on branch A looked "missing in HEAD" from branch B.

Diagnosis recipe that untangled it fast: 1. git worktree list — see which branch each working dir actually has checked out (HEAD != the branch you think). 2. git merge-base --is-ancestor <commit> HEAD in a loop over the commits you *expect* to be present — cheaply proves whether a lineage is reachable. 3. git cat-file -e HEAD:path/to/file — confirm whether a file exists at a ref without checking it out. 4. git log --oneline --graph --all --decorate — the fork point and the two divergent arms become obvious.

Safe landing once you know the shape: if your feature commit's PARENT *is* the real target branch (git rev-parse <commit>^ == target), it's a trivial fast-forward via git branch -f target <commit> — no merge, no cherry-pick. git branch -f works even when the branch isn't checked out in any worktree; it refuses only if some worktree has it checked out. Cherry-pick is the WRONG tool here — it replays a diff against the wrong base and manufactures phantom modify/delete conflicts.

Lesson: when a cherry-pick reports a file "deleted in HEAD" that you know exists, stop and verify which branch HEAD actually points at before resolving anything — you are probably targeting a divergent lineage.