git add –resolved for Conflict Markers

git add –resolved for Conflict Markers

Thesis

git add --resolved (Git 2.56+) stages a path only if conflict markers are gone. It catches the classic failure mode: you “fix” a merge but leave <<<<<<< in the file and git add happily stages the mess.

Mental model

  conflicted path
       │
       ├─ git add file          → stages whatever is on disk (markers OK)
       └─ git add --resolved file
              → refuses if <<<<<<< / ======= / >>>>>>> remain

Worked example

This writing box has Git 2.47.3 — --resolved is not present yet. Confirmed:

Git 2.47.3 on this box; git add --resolved arrived in Git 2.56. Chapter written from release notes and git-add docs.
git version 2.47.3

Documented behaviour (Git 2.56 release notes / docs): after a conflicted merge, edit the file clean, then:

git add --resolved path/to/file
# error if markers remain; stages when clean
git status

Until you upgrade, a cheap guard is:

# pre-2.56 hygiene
if grep -nE '^(<<<<<<<|=======|>>>>>>>)' path/to/file; then
  echo "markers remain" >&2; exit 1
fi
git add path/to/file

Trap

Assuming CI will catch markers. Many test suites never open the conflicted asset (docs, JSON, lockfiles). --resolved (or the grep guard) belongs in the human merge path and in pre-commit hooks.

Boring rule

On Git ≥ 2.56, prefer git add --resolved for every path leaving a conflicted state. On older Git, script the marker grep before git add.

Try this

1. On a 2.56+ lab: leave markers in, watch --resolved fail; remove them and succeed.
2. Add a pre-commit hook that greps staged files for conflict markers.
3. Read the Git 2.56 release notes entry for --resolved.

Sources

• Git 2.56 release notes / git add documentation (--resolved)
• git merge conflict marker conventions (<<<<<<<, etc.)