Signal / 019 — Git 2.56 adds a safer way to mark conflicts resolved

Git 2.56 is out with a small command that solves a familiar, expensive mistake: staging more than you meant to after a merge conflict. The new git add --resolved mode considers only paths currently marked unmerged and checks regular files for leftover conflict markers before it stages anything.

A narrower tool for a dangerous moment

The usual git add -u or git add -A can sweep unrelated working-tree edits into a conflict resolution. According to GitHub’s September 28 release overview, --resolved ignores tracked files that were never conflicted. If a selected regular file still contains conflict markers, the operation reports the path and stages none of the selected files. Pathspecs can narrow the check further.

The release also changes how Git searches for merge bases. Once one side of the history walk has no exclusively painted commits left, Git can stop without missing another common ancestor. GitHub reports large improvements in its monorepo evaluations, including a Linux-kernel example where traversal dropped from 167,441 steps to 3,887. Those are project-reported benchmarks; results will depend on repository shape and commit-graph state.

More tools for big histories

Git 2.56 also removes adoption blockers around path-walk repacking, adds a dry-run-capable bulk cleanup for merged branches, improves rename following through non-linear history, and lets partial-clone users manually discard large recoverable blobs. The experimental git history command gains a drop operation, with important limits around roots, merge commits, and conflicts.

Opinion: git add --resolved is the standout because it gives intent its own command. It does less, and that is precisely why it is safer. Escape the default when the default has a wide blast radius.

AI-assisted summary; sources were reviewed and the article was edited for accuracy and clarity.