Mercurial's changeset evolution is a safety model for rewriting work, not a nostalgia act

This real workshop photograph fits the article because changeset evolution is not just an abstract VCS idea; it is a workflow discipline taught in rooms where teams practice history rewriting, Evolve, and topic-based review together.[6]

Mercurial changeset evolution is easy to underestimate if the only question is whether Git won the default mindshare war. Jordi Gutierrez Hermoso's 2014 Montreal Python talk is useful precisely because it starts from a different problem: developers rewrite draft work all the time, but the tools often treat that rewrite as either a private trick or a destructive operation.[1][2] The talk asks what happens if amended, split, folded, and replaced changesets remain part of a visible lineage instead of vanishing from the model.

That is still a live engineering question in 2026. Mercurial's current help topic on safely rewriting history describes obsolescence markers as metadata that can record deleted or superseded changesets, candidate successors, the rewriting user, and the moment of the rewrite.[3] The same page says this marker history is orthogonal to ordinary file-modification history, which is the key design move.[3] The repository does not merely remember what files changed. It can also remember how a draft patch series changed shape while people were still negotiating it.

Watch the talk as an argument for a safer contract around mutable history. The point is not that every team should switch version-control systems tomorrow. The point is that Mercurial exposes a distinction many tools blur: unpublished work is legitimately mutable, published work should harden, and collaboration gets better when the transition between those states is explicit.[3][4][5]

Image context: the cover uses a real photograph from the Mercurial Paris 2023 workshops, where Raphaël Gomès and Pierre-Yves David led a session on modern Mercurial usage, including history rewriting with Evolve and topics.[6] It is not a screenshot or diagram. It belongs here because the article is about collaborative workflow mechanics, and the photograph shows the social setting where those mechanics become operational knowledge.

Around the opening, the problem is not amendment; it is accountability after amendment

The most important framing in the talk is that rewriting history is normal before review stabilizes. A developer notices a typo, folds a fix into an earlier commit, splits a mixed change, or rebases a stack onto a fresh parent. The dangerous part is not the desire to edit. The dangerous part is losing the relationship between the old draft and the new draft once that edit happens.[1][2]

Mercurial's evolution documentation gives that relationship a concrete storage model. Obsolescence markers can say that one changeset has been superseded by another, and those markers can be exchanged between repositories.[3] That is the difference between deleting an old commit and publishing a map from old work to replacement work. In a single-user repository, the distinction can feel subtle. In a team repository with review queues, non-publishing servers, and parallel local edits, it becomes the whole safety story.

The talk's value is that it makes this lineage visible as a user experience problem. If a teammate has based work on a draft commit you later amend, their child changeset is not simply "wrong." It is an orphan created by a rewrite of its ancestor.[3] A system that can name that condition can help repair it. A system that only sees two unrelated hashes leaves the human to reconstruct intent from chat logs and panic.

Phases are the boundary that keeps mutability from leaking into release history

Changeset evolution only works as a sane model because Mercurial also has phases. The phase documentation defines three states: public changesets are visible on a public server, draft changesets are unpublished, and secret changesets should not be exchanged.[4] By default, new changesets start as draft and move toward public when pushed to a publishing server.[4]

That sounds like metadata, but it is actually policy encoded into the VCS. Evolution depends on the idea that draft and secret changesets can be altered, while public changesets are treated as hardened history.[3][4] This prevents the useful part of history editing from turning into a license to rewrite shared release truth. The user experience becomes more honest: "you may reshape work that has not become public yet" is different from "all history is editable if you are brave enough."

For engineering teams, this is the adoption boundary. Mercurial's model is strongest where review stacks are real objects: long-lived feature queues, topic branches that need repeated polishing, or codebases where reviewers ask authors to rewrite for clarity rather than append cleanup commits forever. The model is weaker when a team has no shared distinction between draft and published state. Without that discipline, obsolescence markers just describe chaos more accurately.

Around the middle, Evolve turns trouble into a first-class object

The Evolve extension is where the talk's concept becomes daily machinery. PyPI describes hg-evolve as the package that supplies the evolve extension for Mercurial and gives changeset evolution a place to mature before pieces move into core Mercurial.[5] It enables changeset evolution, provides distributed history-rewriting commands, issues warning messages when "troubles" appear, and adds an hg evolve command to deal with them.[5]

That word, "troubles," is doing real design work. The Mercurial evolution help page names two main instability classes: orphaning and divergence.[3] Orphans are descendants left behind after an ancestor is rewritten. Content divergence appears when independent rewrites of the same changeset lead to different results. Phase divergence appears when an obsolete version becomes public.[3] These are not moral failures by a user. They are states in a distributed graph.

This is the engineering lesson worth taking from the video even outside Mercurial. Good workflow tools should not merely forbid complex states and then blame users when those states appear. They should name the state, preserve enough metadata to understand it, and offer a repair path. Evolve's commands such as uncommit, fold, split, prune, prev, next, and evolve are interesting less as individual conveniences than as proof that the project treats patch-stack editing as a graph-maintenance problem.[5]

The model also has a real cost surface

The talk is persuasive, but it should not be read as magic. Mercurial's own documentation still labels safely rewriting history as experimental and says the feature remains in development.[3] The Evolve package description likewise says the full implementation of changeset evolution is still in progress.[5] That matters for adoption. Teams should evaluate this as a powerful workflow model with moving edges, not as a frictionless replacement for every review process.

The cost surface begins with shared understanding. Everyone involved needs to know why a changeset can be draft, public, or secret; why a rewrite creates successor relationships; and why an orphan or divergence is repairable state rather than an occasion to clone the repository again.[3][4] The cost continues into infrastructure. Non-publishing repositories, extension compatibility, server behavior, and the willingness to exchange obsolescence data all shape whether the model feels calm or surprising.[3][5]

The reward is that history editing becomes less theatrical. Instead of treating every amend or rebase as a dangerous private stunt, Mercurial can make the act of rewriting part of the collaboration protocol. The old version does not have to be worshipped or erased. It can be marked as obsolete, connected to a successor, and used to stabilize the surrounding graph.

What the talk still clarifies

The best reason to watch this talk now is not nostalgia for an alternate VCS timeline. It is the clarity of the design question. When developers rewrite unfinished work, should the tool pretend the previous version never existed, or should it record the rewrite as a meaningful event?[1][3] Mercurial's answer is unusually explicit: unpublished history can evolve, and that evolution should be represented, exchanged, and repaired with the same seriousness as file history.

That answer has aged well because modern code review keeps increasing the amount of semi-finished work that moves between people. Stacked changes, amend-heavy reviews, patch queues, and branch cleanup are no longer edge behavior. They are daily collaboration. Mercurial changeset evolution remains interesting because it does not ask teams to stop rewriting draft work. It asks them to make rewriting legible enough that the team can keep collaborating after the rewrite happens.

cronfeed.work