Skip to content

SYSTEM Cited by 1 source

git-replay

What it is

git-replay was PlanetScale's internal tool for replaying a sequence of private commits onto a new upstream base branch while memoising how prior merge conflicts were resolved and reusing those resolutions when the same conflict recurred. It was the predecessor to the Vitess cherry-pick bot and bridged the gap between a weekly whole-diff cherry-pick and the continuous PR-level automation that followed.

Named in a single source: "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)

Why it existed

PlanetScale had a growing private diff on top of Vitess. As the team moved from tracking OSS main to also tracking stable release branches (release-22.0, release-x.0, ...), the same conflict started appearing repeatedly — once per release branch. git-replay's core insight was that most of those repeated conflicts had the same structural shape and should be resolved the same way, so a tool could learn the resolution once and apply it to every future occurrence.

What it solved

  • Redundant manual resolution when the same conflict appeared on main, release-22.0, release-x.0, etc.
  • Sequencing: processing private commits in order and keeping the replay deterministic across branches.

See concepts/conflict-resolution-memoization for the general concept.

What it didn't solve

  • Someone still had to run the tool.
  • Unrecognized conflicts — conflicts that didn't match any memoised resolution — still required human intervention.
  • Verification that every commit had actually been cherry-picked required a post-replay diff between the OSS branch and the rebased private branch, followed by manual review by code owners across the repo.
  • Continuous flow from OSS to private was not part of its model — git-replay was an on-demand batch tool, not a bot.

"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. ... We used this tool for several releases, but as our private diffset grew larger than ever before, the limitations of git-replay became increasingly apparent."

Superseded by

systems/vitess-cherry-pick-bot — the continuous PR-level bot with a PlanetScale DB for state and label-triggered backports.

The post does not explicitly state whether the new bot retains git-replay's conflict-memoisation mechanism or discards it in favor of draft-PR-per-conflict escalation. The bot's described behaviour is to "create a PR even if conflicts arise ... the bot creates a draft PR with labels like do not merge and Conflict" — which reads more like a replacement of memoisation with human- escalation than a reuse. If memoisation was kept it's either folded into the bot's pre-PR logic (not described) or retired.

Not to be confused with

  • git replay (lowercase, builtin): Git 2.44+ shipped a native git replay subcommand for rebase-like cherry- pick replaying. That command is unrelated — PlanetScale's git-replay predates it and was an internal tool with custom memoisation behaviour. The name collision is incidental.

Seen in

Last updated · 319 distilled / 1,201 read