Idea: hg merge --close
Pierre-Yves David
pierre-yves.david at ens-lyon.org
Tue Apr 9 10:30:31 EDT 2019
On 4/8/19 8:25 PM, Augie Fackler wrote:
> On Sun, Apr 07, 2019 at 02:02:07PM +0200, Pierre-Yves David wrote:
>>
>>
>> On 4/7/19 12:52 PM, Joerg Sonnenberger wrote:
>>> Hello all,
>>> one thing we discussed during the mini sprint is the issue of dealing
>>> with merged vs active vs inactive branches. At the moment, closing a
>>> branch to get it off the branch list is a separate operation, which can
>>> be annoying. One idea for this is to add a --close flag to merge, which
>>> effectively results in the following topology:
>>>
>>> b1a b2a
>>> | |
>>> | b2b (close=1)
>>> | /
>>> b1b (merge)
>>>
>>> as opposed to the current:
>>> b1a b2a
>>> | /
>>> | /
>>> b1b
>>>
>>> The advantage to having a separate closing commit is that it doesn't
>>> keep a topological head open. The commit message to be used could be
>>> specified as templated option in hgrc, defaulting to something like
>>> 'Closing branch %s after merge' to so. The one downside is that the
>>> parent of b1b now points to an artifical commit, which makes the history
>>> a bit more messy.
>>
>> I like the idea[1], people having been asking for a simple UI for `hg merge
>> --close` for a long time. The approach of creating an extra changeset lift
>> the "clarity" concerns raised in previous discussions around `hg merge
>> --close`.
>
> I was about to ask what the concerns were around this in the past,
> because I know it's come up. I think this solves the problem nicely,
From my memory¹ of previous discussion, the last time it came up the
idea was to have the merge changeset (on branch A) to old the closing
information (for branch B). This was rejected by Matt on the argument
that it could be too confusing for user to have the closing information
in a non-obvious location. It was also incompatible with older client
since "closing another-branch" would have been a new feature.
Nowadays, it is much simpler to create in-memory commit and generate
this extra closing commit, lifting both "obviousness" and
"compatibility" concerns.
Once we have this kind of automatic closing in place, we can probably
look into ways to automatically triggers it in some occasion. I am CCing
Sean Farley to this conversation since it bare similarities with his
draft-branch work.
For the record, at the mini-sprint, we also discussed a variation of
this, using a dangling closing heads (schema below). Using a dedicated
topological head comes with more troubles. Various algorithms suffer
from them and such closing tend to "breaks" when `hg clone --rev` or `hg
pull --rev` is used. So we favored the approached Joerg described.
a
_ |
|/|
| |
b a
Regards.
--
Pierre-Yves David
More information about the Mercurial-devel
mailing list