Skip to content

CONCEPT Cited by 1 source

Conflict-resolution memoization

Definition

Conflict-resolution memoization is the technique of recording the human-resolved outcome of a merge or cherry-pick conflict and automatically re-applying that resolution when the same (or a structurally-equivalent) conflict recurs. It trades storage of past resolutions for elimination of repeated manual work on the same three-way-merge problem.

The canonical Git-native mechanism is git rerere ("reuse recorded resolution"), which hashes the conflict markers and stores per-hash resolutions locally. Custom tools like PlanetScale's systems/git-replay have built similar mechanisms tuned to their specific workflow.

Why it matters in fork-sync

In fork-upstream sync, particularly when a fork tracks multiple OSS release branches, the same conflict tends to appear multiple times — once per release branch the fork mirrors. Without memoization, every appearance is a fresh manual resolution. With memoization, the first resolution is recorded and the rest are applied automatically.

From the PlanetScale post: "One of our early observations was that when cherry-picking private commits onto multiple release branches, we frequently encountered the same conflicts repeatedly. To address this, we developed a tool that could sequentially process all relevant commits and replay them on top of the open-source (OSS) branch. This tool, aptly named git-replay, could store how specific conflicts were resolved during cherry-picks and reuse that information to resolve similar conflicts in the future." (Source: sources/2026-04-21-planetscale-automating-cherry-picks-between-oss-and-private-forks)

Mechanism shape

Typical implementations:

  1. On first conflict, record:
  2. The conflict signature (hash of conflict markers, or hash of the three sides: base + ours + theirs).
  3. The human's final resolution (the chosen merged form).
  4. On subsequent conflicts, look up the signature and if it matches, apply the stored resolution without prompting.
  5. On signature miss, fall back to human intervention; record the new resolution for next time.

Limitations (and why bots move past it)

Memoization has structural limitations that surface at scale:

  • Signature fragility — subtle changes to the surrounding context can shift the conflict hash and force re-resolution of what a human sees as "the same conflict."
  • No causal reasoning — a stored resolution from six months ago may be wrong for today's codebase if the semantics of the surrounding code have changed.
  • Someone still has to run it — memoization accelerates batch replay but doesn't eliminate the run-the-tool loop.
  • Unrecognised conflicts stay manual — first-time conflicts block progress until a human resolves them.
  • Verification overhead — a post-replay audit diff + code-owner review is typically required to trust the result.

PlanetScale's retrospective makes this trade-off explicit: "While git-replay was a significant improvement over our previous manual process, it wasn't without its limitations. Someone still had to run the tool, manually resolve any unrecognized conflicts, and verify that all changes were correctly cherry-picked." Their next generation (systems/vitess-cherry-pick-bot) swapped memoization for draft-PR-on-conflict — a bot doesn't try to be smarter than a human, it just opens a draft PR with the conflict and tags the original author.

When memoization is the right call

  • Fork diff is stable, OSS churn is localised — signatures stay valid across replays.
  • Number of release branches × number of private commits is large enough that manual per-branch resolution is the dominant cost.
  • Team is willing to maintain the memoization store (Git rerere caches are notoriously drift-prone in team settings).

When draft-PR escalation is better

  • Private diff changes rapidly and stored resolutions go stale fast.
  • Conflict rate is low enough that humans can clear them as they arrive.
  • Accountability matters — tagging the original PR author on every conflict creates a clear owner.

Seen in

Last updated · 319 distilled / 1,201 read