Gilles Moris <gill...@free.fr> writes:

Yeah, there will be the problem of how to discover or re-find the dead heads since I think they should be skipped in 'hg log' by default (not hidden from other parts of Mercurial, just hidden in by default in the various log viewers).

But then again, with an option to 'hg log', 'hg grep', etc. for showing dead changesets, then I don't think the problem is all that big.

Jan had some ideas for building a cache that would be used to track if a changeset is considered dead or alive. A changeset is alive when it is the ancestor of a head that is alive. So figuring out if revision 1 is alive could take a while with 100,000 changesets (hi Greg! :-)

I also don't know the algorithm and the capabilities in detail.

Indeed -- in some sense one can just leave the dangling heads there, but Mercurial is currently made in such a way that it's an uphill fight to have multiple heads.

So I basically think we need a way to say to Mercurial: "yes, I know there is an extra head, but I've marked it as dead/closed -- please stop bothering me" :-)

Excluding the dead heads from push/pull will furthermore solve the problem people have when they have made a mess and don't want to push it anywhere. Just today a guy came by on IRC who had managed to commit the same change at three different places in his history. Now Mercurial (wisely) told him that he would create multiple heads on push and he was very confused... It would have been great to tell him to do

hg update first-troublesome-head hg commit --mark-dead (or --kill, --murder, etc :-) hg update second-troublesome-head hg commit --mark-dead hg push

Instead I tried to get him to make a good clone with 'hg clone -r', but he said his repository was too big... he just wanted to get rid of the extra heads. Strip would have been an option, but marking them as dead would have been even nicer.

aragost Trifork Professional Mercurial support http://aragost.com/mercurial/