RFC: dealing with dead, anonymous feature branches

Martin Geisler mg at aragost.com
Sat May 8 03:32:04 CDT 2010


Gilles Moris <gilles.moris at free.fr> writes:

> On Friday 07 May 2010 07:34:23 pm Martin Geisler wrote:
>> My idea is a simple: we already have the --close-branch flag for
>> commit which inserts close=1 in the extra dictionary. Call such a
>> head "closed", other heads are "open". I propose that we do not push
>> or pull closed heads.

Let's say the heads are "dead" or "alive" instead and talk about pushing
and pulling dead history. I like those names better.

> I am not sure this is the direction I would like to see happen. I
> understand that "closed history" can cause some cluttering, but I
> think not sending some changesets on push/pull is a disruptive
> behavior. Do we already do that in some situation, except explicitly
> requested through a "-r" option. And after all, closed history is
> history, so why not push it anyway ?

Marking some history as dead gives you a way to make it go away without
deleting it completely. Instead of introducing "kill changeset" that
tells hg to strip REV when pulled, this does a similar thing but in a
way where changesets are never deleted.

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 dead branches would wither away over time as new clones are made
since the clones would prune dead branches.

> I am more concerned the close-branch behavior itself. May be I am
> stupid, but I have hard time to understand the logic behind the
> current implementation. [...]

No, I agree with you and your requirements. They sound like the way I
have also imagined closed heads to work.

So I'm suggesting something stronger than you: dead heads behave like
"Gilles-style" closed heads and they are not pushed or pulled.

-- 
Martin Geisler

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


More information about the Mercurial-devel mailing list