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