[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