History Editing Pre-Checking consolidation

Status: InProgress

Main proponents: Pierre-YvesDavid, PulkitGoyal, SushilKanchi, GregorySzorc

A way to reduce the odd for users to be exposed to evolution instability (both for local and distributed workflow).

1. Goal

Changeset Evolution can automatically detect and solves a lot of the issues that can arise from history rewriting. However, in terms of user experience it is better to prevent them to arise in the first place as much as possible. We already have some some "pre-checking" in place, it should be generalized to make sure that every history rewriting operation uses it and that it cover all the issues we can cover.

This plan page aims at:

• listing all the situation we want to handle,
• define the UI/UX we want for them,
• define the technical means to achieve this.

2. Details

2.1. checks

Things that needs to be checked:

• rewriting of public changesets

• creation of orphans (configurable /overwritable)

• creation of content-divergence (configurable/overwritable)

• creation of phase-divergence (configurable/overwritable)

• rewriting of changeset non-owned/unrelated-to the current user

2.2. API

We also need to make sure any local markers creation goes through this. We could use the follow API for this purporse (Actual name may varies):

with history_rewriting(repo) as evolution_tracker:
    evolution_tracker.pre_check(some, arguments)
    work(); work(); work();
    evolution_tracker.record_evolution(markers, to, be, created)

The evolution_tracker tracker become the only way to create local markers, and the markers creation will checks that an appropriate "pre_check" call have been made for the rewritten changesets.

2.3. Ownership

The idea is to help preventing content-divergence creation and large impact error in general by detecting when a user is about to rewrites changeset that are not is own.

There are two dimension to consider:

what changeset should we "protect" ?

• By default a changeset is consider "non-owned" is ctx.username != ui.username.

• A config option ui.altername-username can define more usernames for the current user.

• Another dedicated config option controls the changeset "protected" (e.g. rewrite.no-warn-edit=pulkit@yandex,babar@savanah.ni).

• A wild-card value removes protection for all changesets rewrite.no-warn-edit=*

how should we act on ?

• By default a prompt is offered to the user:

  • You are about to rebase 12 changesets of another user, do you want to continue [yN]
    See `hg help evolution.other-people-change` for details

• We can offer an option to plain abort or disable any warning through the config
• It might be useful to offer fine grained configuration for various groups of users.

3. Roadmap

• Add instability detection with basic overwrite through experimental configuration

  • orphans

  • content-divergence

  • phase-divergence

• Get all history rewriting command to use pre-checking

  • amend (in-evolve)

  • evolve ? (in-evolve)

  • fold (in-evolve)

  • metaedit (in-evolve)

  • pick (in-evolve)

  • rewind (in-evolve)

  • split (in-evolve)

  • topic (in-evolve)

  • touch (in-evolve)

  • uncommit (in-evolve)

  • histedit (in-hgext)

  • rebase (in-hgext)

  • commit (in-core)

  • branch (in-core)

  • phabsend (in-hgext)

  • amend (in-hgext)

  • split (in-hgext)

  • fold (in-hgext)

  • uncommit (in-hgext)

  • absorb (in-hgext)

• Make the use of pre-checking mandatory

• add ownership related configuration and UX

• improve UI/UX around instability prevention to their final state

4. See Also

• ChangesetEvolutionDevel

• ChangesetEvolution

CategoryDeveloper CategoryNewFeatures CategoryEvolution