Git 2.56 ships its conflict-marker check as a flag that scripts and agents must opt into

Resolving a merge conflict usually ends with `git add` on the files you fixed ^[2]. According to devops.com's account of Git 2.56, that step goes wrong in two ways: an unrelated change gets staged along with the fix, or a file that still has conflict markers in it gets staged ^[2]. It is easy to read the release as a safety upgrade that comes with the install. The write-up does not describe any change to plain `git add`. The new check runs only when a person or a script passes `--resolved` ^[3].

The speed improvements do come with the install. In the benchmarks devops.com reports, Git now finds merge bases faster because it stops walking history once it has what it needs ^[4]. Merge-base calculations run inside merges, rebases and CI pipelines ^[6]. One monorepo case fell from 0.68 seconds to 0.01 seconds ^[5].

The diff fix is narrower than its headline figure. It removes quadratic scans from path-limited working-tree diffs, and the eight-minute case was measured on a Chromium checkout with roughly 500,000 index entries ^[7]. That case got about 6,900 times faster ^[2].

Storage savings need a flag of their own. Path-walk repacking still has to be switched on with `--path-walk` ^[9]. Partial-clone teams also get `git repack --drop-filtered`, which removes blobs matching a filter such as files over 1 MB and fetches them again when they are needed ^[11].

The devops.com summary says the new branch-cleanup, repacking and history options give "guardrails and automation opportunities" to developers and AI coding agents ^[15]. The agent case I would put first is scripted conflict resolution, because no person reads the file before it is staged. An abort there is a failure the pipeline can see. The experimental `git history drop` aborts on conflicts and does not yet handle merge commits ^[14]. I would keep agents away from it while it is still experimental.

I'd change the staging step in those scripts first. The cost is that an aborting `git add` will stop some agent runs that used to finish ^[3]. Someone then has to decide what the agent does after the abort, either hand off to a human or fail the job.

For the rest of the release, two questions sort each change. The first is whether it pays out on upgrade or only after someone edits a command. The second is whether the pain it removes already shows up in your CI timings or incident notes. An automatic change to a pain you already measure is worth timing before and after, starting with the merge and rebase steps in CI. When the change is automatic and the pain is absent, it can go out on the normal upgrade schedule with no announcement. An opt-in change to a pain you have means an edit: the conflict script or the agent's staging step calls `--resolved`, and the largest repository gets a `--path-walk` trial. The last cell, opt-in with no pain, can wait, and for most teams I would put the experimental history commands there.