obscolescence markers are rebase without losing any history?

[Simon King]

On Tue, Aug 19, 2014 at 2:50 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> On Tue, Aug 19, 2014 at 2:43 PM, Simon King <simon at simonking.org.uk> wrote:
>> On Tue, Aug 19, 2014 at 11:02 AM, anatoly techtonik <techtonik at gmail.com> wrote:
>>>
>>> Do obsolescence markers on server side allow rebasing
>>> named branches without losing history?
>>>
>>> If there is a second repository with commits on top of
>>> named branch, will these commit automatically move to
>>> a top of rebased named branch after the pull?
>>>
>>
>> I don't think anything will happen automatically. After the rebased
>> changes are pulled into the second repository, the commits on top of
>> the old branch will be considered unstable and you'll need to call "hg
>> stabilize" to rebase them:
>>
>> http://hg-lab.logilab.org/doc/mutable-history/html/tutorials/tutorial.html#rebasing-unstable-change-after-pull
>
> This `hg stabilize` command is magic. How does it know that ffa2 is
> a successor of 8a79? Is it possible to see DAG with evolution links
> somehow (different color, for example)?
>
> o  9ac5d0e790a2 (draft): animals
> |
> | @  ffa278c50818 (draft): bathroom stuff
> | |
> x |  8a79ae8b029e (draft): bathroom stuff
> |/
> o  a2fccc2e7b08 (public): SPAM SPAM
>

That's exactly the point of the obsolescence markers - they record
that ffa2 is the successor of 8a79.

hgview shows the obsolescence relationships using dotted lines (see
the screenshot at http://www.logilab.org/project/hgview)

Simon