RFC: dealing with dead, anonymous feature branches

Martin Geisler mg at aragost.com
Mon May 17 03:10:21 CDT 2010


Sune Foldager <cryo at cyanite.org> writes:

> On 08-05-2010 10:48, Martin Geisler wrote:
>
> [...]
>>> And both approaches still introduce a completely new and not
>>> particularly Mercurial-like notion of "hidden changesets". Thinking
>>> about how those might be implemented and their side effects makes me
>>> nervous.
>> 
>> Me too, I think it would be a fairly invasive change. However, that
>> last paragraph about hidden merge changesets was not meant to be the
>> important part :-)
>
> I agree, I think the RFC sounds pretty interesting, although I don't
> necessarily like the part about the hidden merge very much. I think
> the rest would be nice addition, if we can make it work well :)

Let's forget the idea about hidden merges. Like Matt said, it's not very
Mercurial-like to hide changesets and introducing such a concept would
open up a whole new set of things to worry about.

The core idea is simple: do not push/pull/clone dead branches.


I don't know if people will see this as just a halfhearted way of
supporting remove deletions, as if we couldn't figure out how to do a
"proper" server-side deletion.

I just tried to figure out how Git supports this. There you need to push
your branch name with a colon (?!) and others need to run a prune
command from what I can tell:

  http://github.com/guides/remove-a-remote-branch

I think the proposed solution would be more user friendly. We will have
to take care to warn users when they pull in a changesets that causes
the working copy parent changeset to be dead too.

> One problem is that cloning from servers which have a lot of closed head
> (somehow), will be slower since the streaming protocol can't be used.
> For me personally, this is not an issue as I hardly ever do full clones
> like that, and I don't know how big the speed difference is anyway.

Is it the streaming protocol enabled by server.uncompressed you mean, or
cloning in general?

  http://www.selenic.com/mercurial/hgrc.5.html#server

-- 
Martin Geisler

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


More information about the Mercurial-devel mailing list