[PATCH rfc] branches: introduce closing of other heads on other named branches

Matt Harbison mharbison72 at gmail.com
Sun Oct 25 10:35:14 CDT 2015


On Sun, 25 Oct 2015 03:37:53 -0400, Didly <didlybom at gmail.com> wrote:

> On Sun, Oct 25, 2015 at 3:45 AM, Matt Harbison <mharbison72 at gmail.com>  
> wrote:
>> On Sat, 24 Oct 2015 20:47:01 -0400, Didly <didlybom at gmail.com> wrote:
>>
>>> On Sun, Oct 25, 2015 at 2:02 AM, Mads Kiilerich <mads at kiilerich.com>
>>> wrote:
>>>>
>>>> # HG changeset patch
>>>> # User Mads Kiilerich <madski at unity3d.com>
>>>> # Date 1445731342 -7200
>>>> #      Sun Oct 25 02:02:22 2015 +0200
>>>> # Branch stable
>>>> # Node ID ee590daabd2fe53685f14289db72aa03faeb2cb1
>>>> # Parent  39dbf495880b8a439d912091109427d27a7e616a
>>>> branches: introduce closing of other heads on other named branches
>>>>
>>>> Closing of named branches was problematic. Especially when a lot of
>>>> branches
>>>> were used and there was a need for closing them so they no longer  
>>>> showed
>>>> up.
>>>> Closing a branch required a commit on the branch. That created an  
>>>> extra
>>>> head on
>>>> the branch. To make sure that users who had the changesets from the
>>>> branch also
>>>> had the close commit, the close had to be done before merging  
>>>> anywhere,
>>>> or an
>>>> additional merge had to be done. That became even more troublesome  
>>>> when
>>>> branches were nested so merging one branch actually also introduced
>>>> several
>>>> other unclosed branch heads in the ancestry. The extra commits on
>>>> branches
>>>> could also often end up causing multiple heads on the branches if
>>>> development
>>>> was continued elsewhere anyway.
>>>>
>>>> Instead, make it possible for commits to also mark existing commits as
>>>> closed.
>>>> With --other-close REVSET, all the branch heads in that revset will be
>>>> marked
>>>> as closed in meta data of the commit.
>>>>
>>>> For general commits of closing all ancestor branch heads, use  
>>>> something
>>>> like:
>>>>   hg commit --other-close "::parents()"
>>>>
>>>> For more efficient closing of just the branches that has been merged,  
>>>> use
>>>> something like:
>>>>   hg commit --other-close "only(p2(),p1())"
>>>
>>>
>>> Since there is already a --close-branch flag, perhaps a better name
>>> for this would be --close-branches ?
>>
>>
>> That seems too subtly different from the original spelling wise.  Why  
>> not
>> just let the existing --close-branch take a revset, and if none is  
>> given,
>> '.' is implied?
>
> I don't think that is possible. Command line parmeters can either take
> no arguments or take arguments, but not both.

Ah, OK.  I wasn't aware of this restriction, but it makes sense with what  
pyd said.

> It is true that it is a bit subtle, but IMHO it is understandable. In
> one case you close _the_ branch and on the other you close _some_
> branches. In any case I'm sure we can find something better than
> --other-close which does not mention branch and in fact will let you
> close the current branch (i.e. not just _other_ branches).
>
> What about --close-branch-set or --close-branch-revset or
> --close-multiple-branches or --close-some-branches ?

We should probably stay away from -revset in the name.  I can't tell if  
the implementation would support just naming a single rev number or branch  
name, but I can see (the former anyway) being useful to close some head  
without updating.  And it seems like the graph drawing for this mechanism  
could always put the '_' close to the head it closes?  Compare that to  
what currently happens when closing an old head, and you get a really long  
line to the closing commit.

I was going to suggest simply '--close', since it reads naturally on the  
command line (i.e. --close __), but I see Mads already responded about  
that in the other message.

The important thing that I forgot to mention is that convert needs to  
learn how to rewrite these markers in extras like it does for amend, etc,  
so this style close doesn't reopen after a conversion.  It's too bad  
convert can't recognize hash values and change them automatically, no  
matter what the key name is.


>
> Angel


More information about the Mercurial-devel mailing list