git-cherry-pick-continue-accepts-unresolved-markers
git cherry-pick --continue accepts files with unresolved conflict markers if the index is marked resolved
Git’s merge-state resolution is INDEX-level, not content-level. git add <path> tells git “this file is resolved” — it does NOT verify the file’s contents actually resolved the <<<<<<< / ======= / >>>>>>> markers. So a cherry-pick sequence like:
git cherry-pick <sha> # conflicts
# (Edit tool fails due to Read-first requirement, but the session doesn't catch it)
git add <conflicted files>
git cherry-pick --continue # SUCCEEDS, producing a commit with markers still in source
…will land a “clean” commit where <<<<<<< HEAD, =======, and >>>>>>> <sha> literals are embedded inside committed Python/JS/whatever files. SyntaxError only surfaces at runtime or import.
Verification discipline — ALWAYS before git add + --continue:
grep -l "^<<<<<<<\|^=======$\|^>>>>>>>" <modified files> # must be empty
python3 -c "import ast; ast.parse(open('file.py').read())" # second line of defense per-file
Recovery: if markers leaked into a commit — re-resolve, git add, git commit --amend (preserves cherry-pick identity). Force-push only if pushed to a feature branch (never to main/master).
Cross-agent applicability: any agent doing automated cherry-pick sequences (bulk ports, rebase automation, cross-fork patching) must include this verification step or risk silent syntax corruption in committed code.