This page is primarily intended for Mercurial's developers.
This page is no longer relevant but is kept for historical purposes.
This page aims to sum up related to rewriting history in Mercurial.
Hidden changesets: Implemented in 1.9.0
Changeset phases: Implemented in 2.1.0 see Phases page for details
Abandoned changeset: ???
ChangesetsObsolescence: partially implemented in 2.2.3
2. 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.
Hidden changesets can be shown with the --hidden flag, eg 'hg log --hidden' will show all changesets.
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.
3. Changeset phases (previously known as states)
See Phases for details.
4. 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 phases 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.
Abandoned concept is dedicated to taking care of unwelcome but yet immutable changeset.
To mark a branch as abandoned, use 'hg commit --abandon' to abandon the working directory and its descendants.
The abandon commit contains an explicit list of abandoned changesets.
4.3. Legacy clients
Old clients see abandoned changesets and their marker commit as normal changesets.
5. Changesets Obsolescence
ChangesetsObsolescence 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 phase concept since obsolete markers are implemented as pointers from X' (new changeset) to X (obsolete changeset).
Obsolete markers record the result of history rewriting. When a changeset is rewritten by some history rewriting operation, instead of striping the old version from the repo we just register the information that the result of the rewriting operation replaces the old changeset. This information then allow to easily hide the old changeset, detect inconsistent states and resolve conflicts.