RFC: dealing with dead, anonymous feature branches

[Martin Geisler]

Martin Geisler <mg at aragost.com> writes:

> One could perhaps even use dead heads when rebasing: build the new
> history and mark the old head as dead. When you push you will only
> push the new history and you will still have the old history around
> for reference. This is very similar to 'hg rebase --keep', except that
> a future push would know not to push the kept changesets.

The same for strip -- it would just be an alias for 'hg commit
--mark-dead' or 'hg commit --kill', if you will. We could put all sorts
of history-amending commands into core if they worked like this...


We all know that you shouldn't rebase/strip/histedit public changesets.
If you do, then you'll end up with (warning about creating) two heads
afterwards.

With dead branches thins work a little different. If I start with

  [A] --- [B] --- [C]
     \
      [X] --- [Y]

and by mistake rebase the public [B], [C] onto my own [X], [Y], then I
get:

  [A] --- [B] --- [C] --- <D>
     \
      [X] --- [Y] --- [B'] --- [C']

where <D> was added by rebase to mark the branch dead in my clone.

If nothing new has happened on the server, then I push this graph there
since there's only one living head after the push. New clones will use
my [C'] and I've effectively propagated a rebase to the server(!).

However, if people have already made work based on [C], then depending
on who pushes first to the server, one of us gets the warning about
creating multiple heads. So unlike today, the innocent (non-rebasing)
guys can get in trouble if I rebase public changesets.

-- 
Martin Geisler

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