Mutable Mercurial

This page is intended for developers

1. Introduction

This page aims to sum up related to rewriting history in mercurial

2. Status

• Hidden changesets: Implemented in 1.9.0

• Changeset phases: being implemented for 2.1.0 see StatePlan page for details

• Abandoned changeset: ???

• ChangesetEvolution: experimental extension exists here: https://bitbucket.org/marmoute/mutable-history/overview

3. Hidden changesets

Since various features will require changesets to be hidden by default, it makes sense to implement a centralized method to deal with this property.

3.1. Usage

Hidden changesets can be shown with the --hidden flag, eg 'hg log --hidden' will show all changesets.

3.2. Implementation

The changelog object contains a _hidden set (using revision numbers) that log and other commands consult. To hide a changeset, add it to the set at startup. Contexts are given a .hidden() predicate that consults the set.

4. Changeset phases (aka states)

See StatesPlan for details.

5. Abandoned changesets

Abandoned changesets are changesets that have been marked as 'no longer relevant'. Like dead changesets, they are hidden, but abandoned changesets are implemented via markers in history so they are not part of the states concept.

Abandoned changesets are not pushed or pulled (see the implementation of local) but are not subject to garbage collection.

Abandoned changesets can be unabandoned by committing new descendants.

5.1. Usage

To mark a branch as abandoned, use 'hg commit --abandon' to abandon the working directory and its descendants.

5.2. Implementation

The abandon commit contains an explicit list of abandoned changesets.

5.3. Legacy clients

Old clients see abandoned changesets and their marker commit as normal changesets.

6. Obsolete changesets

Obsolete changesets are part of an advanced concept (see ChangesetEvolution) used to automatically resolve and combine refactoring operations between collaborators using liquid changesets. Obsolete changesets are hidden, but are not part of the state concept since obsolete markers are implemented as pointers from X' (new changeset) to X (obsolete changeset).

Obsolete markers record result of history rewriting. When a changeset are rewritten by some history rewriting operation, instead of striping the old version from the repo we just registered the information than the result of the rewritting operation replace the old changeset. This information then allow to easily to hide old changeset, detect inconsistent state and resolve conflict.