Note:

This page is primarily intended for developers of Mercurial.

Mercurial Hidden Commits Proposal

Status: Project

Main proponents: DurhamGoode

Goal: To define a unified user experience for hiding commits, and concrete steps to make it happen in core.

For this document, ignore all current changesets hiding user experience done by obsmarkers. Differences with obsmarker based hiding are covered below.

High Level Approach

We can ship a user experience where changesets are hidden only when users perform an explicitly destructive action, and can be unhidden trivially and without hard-to-undo consequences. In today’s terms, we would hide changesets during amend, rebase, histedit, shelve, and strip (or some new command with the goal of hiding changesets). Basically, anywhere that currently uses repair.strip() can instead hide changesets.

hg journal (an extension that already exists in core) is used to find old hashes. A changeset could be unhidden via:

Interaction With Obsmarkers

Obsmarkers would have no effect on hiddenness. Obsmarker information would be conveyed to a user via other means (ex: log/smartlog) outside the scope of this document. hg hide would have an option to hide changesets that obsmarkers unambiguously indicate are no longer necessary.

Steps To Make It Happen (by the 4.3 release)

Benefits Of This Approach

Downsides Of This Approach


Notes On Differences With Obsmarker Based Hiding

Reminder: Obsmarker hiding can be turned on today in core with the "experimental.evolution=all" configuration.

Obsmarker based hiding today works as follows. A changeset is hidden if:

This pattern has several consequences:

The proposed solution differs in several ways:

Effect On Enabling Hidden Changesets In Core


CategoryDeveloper CategoryNewFeature

HideUnhidePlan (last edited 2017-04-21 17:30:44 by Pierre-YvesDavid)