[PATCH] add support for marking changesets as dead

[Henrik Stuart]

On 2011-01-31 21:34, Idan K wrote:
> On Mon, Jan 31, 2011 at 12:10 PM, Martin Geisler <mg at aragost.com
> <mailto:mg at aragost.com>> wrote:
> 
>     ... 
> 
>     A dead head is propagated if and only if it kills a head.
> 
>     To illustrate this, consider the repository:
> 
>      0 ---- 1 ---- 2 (dead)
>       \
>        ---- 3
> 
>     Where the other repository has:
> 
>      0
> 
>     After a pull/push, the other repository would just get changeset 3.
>     Had the other repository been:
> 
>      0 ---- 1
> 
>     It would receive both changesets 2 and 3 after a pull/push since 2
>     kills the local non-dead head 1.
> 
> 
> Hi,
> 
> I may have missed an earlier discussion about this (sorry for the noise
> if so) but the behavior described in your second example scares me. 
> If I understand correctly a simple pull operation could vanish a bunch
> of changesets from my repository without me knowing (in the sense that
> they won't appear in 'hg log' without explicitly asking for them). 
> It's not exactly editing my history but it's making it look like someone
> else has which to me seems like something Mercurial has been trying to
> make the users very aware of and here it's happening out of the box.

The earlier discussion has happened here:
http://markmail.org/message/vyyjfyshhnb5acpc

There is no editing of history happening, only marking of dead
development (mistakes, abandoned projects, etc.).

It is not very common to just run hg log and watch thousands of commits
scroll by, usually you will use a revision set and there they will show
up unless you suffix "not dead".

What Mercurial has and most likely will keep on doing, is support
destructive operations on its revlogs.

> And something else that just popped to my mind, what will happen if I
> have changeset 1 (from your second example) currently checked out? Will
> it also disappear from 'hg log' after a pull?

You'll still be at changeset 1, you can commit and now you have revived
changeset 1 (there is a non-dead head making it active, so to speak).

> Also, if I think of how git behaves in this manner, there you have to
> explicitly ask git to remove 'dead' remote heads (git remote prune origin).

I don't really endeavour for git's user interface.

-- 
Kind regards,
  Henrik Stuart