XXX starts by talking about getting ride of changeset.

XXX missing lines ?

I'm not claiming that rewriting history is impossible. People are successfully

doing for years. However they all need to work around this unstability:

The simplest way to avoid unstability is to ensure rewritting operation always

ends in a stable situation. This is achieve by rewriting all impacted changeset

at the same time.

rewritting all descendants at the same time that the rewritting of a changeset.

::

  Schema!

Several Mercurial command follow this idea: rebase, collapse, histedit.

Mercurial also refuse to amend changeset with descendant.  The git brnach design enforce such approach in git too.

However, DVCS are **Distributed**. This means that you do not control what

happen outside your repository. Once a changeset have been exchanged *outside*,

you can't be sure of it's descendant. Therefore** if you rewritte changeset that

exists elsewere, you can't erradicate the risk of unstability.**

Do not rewrite exchanged changeset

```````````````````````````````````

To work around this issue mercurial introduced phases that prevent you to

rewrite exchanged changeset and ensure other can't pull certain changeset from

you. But this is a very frustrating limitation that prevent you to

efficiently share, review and collaborate on mutable changeset.

Git world use another approach to prevent unstability.

By convention only a single developper works on a changeset contained in a named

branch. But once again this is a huge blocker for collaborating and clueless people

**will** mess up social convention soon or later.

The other approach use in Mercurial is to keep the mutable part of the history

outside the DVCS constraint. This is the MQ approach of sticking a quilt queue

over Mercurial.

This allow much more flexible workflow two major feature are lost in the

process:

  * Graceful merge. MQ use plain-patch to store changeset content and patch have

    trouble to apply in changing context. applying you queu can because very

    painful if context changeset.

  * easy branching. A quilt queue is by definition a linear queue.

It is possible to collaborate over versionned mq! But you are going ahead a lot

of trouble.

.. Ignore conflicts

.. ```````````````````````````````````

.. 

.. Another ignored issue is conflicting rewritting of the same changeset. If a

.. changeset is rewritten two times we have two newer version, duplicated history

.. complicate to merge.

.. 

.. Mercurial work around by

.. 

.. The "One set of mutable changset == One developper" mantra is also a way to work

.. around conflicting rewritting of changeset. If two different people are able to

.. 

.. The git branch model allow to overwrite changeset version by another one. But it

.. does not care about divergent version. It is the equilent of "common ftp" source

.. management for changeset.

Obsolete marker can handle the job

```````````````````````````````````

mercurial called "Obsolete marker". Obsolete marker have two key property:

  by history rewritting operation.

  By explicitly marking the obsolete part of the history, we will be able to

  easily detect appearance of unstability. 

  By Storing a meta-history of changeset evolution we are able to easily resolve

  instability and edition conflict [#]_ .

.. [#] edition conflict is another major obstable to collaboration. See the

       section dedicated to obsolete marker for details.

Improving robusness improves simplicity

````````````````````````````````````````````````

This proposal should **first** be seen as a safety measure.

It allow to detect unstability as soon as possible

::

    $ hg pull

    added 3 changeset

    +2 unstable changeset

    (do you want "hg stabilize" ?)

    working directory parent is obsolete!

    $ hg push

    outgoing unstable changesets

    (use "hg stabilize" or force the push)

And should not not encourage people to create unstability

::

    $ hg up 42

    $ hg commit --amend

    changeset have descendant.

    $ hg commit --amend -f

    +5 unstable changeset

    $ hg rebase -D --rev 40::44

    rebasing already obsolete changeset 42:AAA will conflict with newer version 48:BBB

While allowing powerful feature

````````````````````````````````````````````````

* "kill" changeset remotely.

* track resulting changeset when submitting patch//pull request.

* Focus on what you do:

  I do not like the "all at once" model of history rewriting. I'm confortable

  with unstability and obsolete marker offer all the tool to safely create and

  handle unstability locally.