Skip to content

CONCEPT Cited by 1 source

Mutation history (commit)

Mutation history is VCS metadata that tracks how a commit has evolved over time — every amend, rebase, fold, split, or other mutation produces a new commit, and the mutation history records the lineage "commit X was produced by amending commit Y, which was produced by rebasing commit Z."

The underlying insight: a VCS that wants first-class stack editing has to remember the identities of old-and-new commit pairs so it can algorithmically reconstruct the stack after the user edits it. Without mutation history, every amend invalidates the stack and the user has to rebase-by-hand.

Genealogy: Mercurial Evolve → Sapling

The concept originates in Mercurial's Evolve extension (Mercurial's changeset-evolution system, circa 2013). Sapling adopts the mechanism directly. Per the 2022-11-15 Sapling announcement:

"Inspired by Mercurial's Evolve extension, Sapling keeps track of the mutation history of each commit under the hood, allowing it to algorithmically rebuild the stack later, no matter how many times you edit the stack."

— Sapling announcement post

What it enables in Sapling

  • sl restack — automatic rebuild of the whole stack after any amend, rebase, fold, or split in its middle. Without mutation history, this would require remembering the old→new commit mapping by hand for each mutation.
  • sl undo / sl unamend — can revert a specific operation on a specific commit by following the mutation lineage backward.
  • sl hide / sl unhide — commits are hidden (not deleted); the mutation history keeps enough state to bring them back.
  • Deferred conflict resolution — "If you choose not to fix the conflicts now, you can continue working on that commit, and later run sl restack to bring your stack back together once again." Mutation history lets Sapling remember "there's an unresolved stack here" across arbitrary intervening work.

Contrast with Git

Git's reflog tracks ref movements, not commit mutations. After git commit --amend, the old commit is referenced only by the reflog's record of HEAD's previous value — the new commit doesn't "know" it came from amending the old one. Rebase + amend workflows in Git are stateful in the user's shell history, not in the repository; automation of stack-edit operations is fragile.

Git Extensions like git-branchless (2021+) retrofit a mutation-history equivalent onto Git — direct acknowledgment that the feature is missing from vanilla Git.

Seen in

Last updated · 319 distilled / 1,201 read