[PATCH 6 of 6 bid merge v2] [RFC] merge: take bids for merge actions for different ancestors and pick the best

Tue Apr 22 03:05:21 CDT 2014

Mads Kiilerich <mads at kiilerich.com> writes:

> On 04/21/2014 03:28 PM, Martin Geisler wrote:
>> Mads Kiilerich <mads at kiilerich.com> writes:
>>> This has been merged for 3.0.
>>>
>>> Bid merge is enabled by setting the configuration value
>>> "merge.preferancestor=*". With this setting, Mercurial will perform a
>>> bid merge in the cases where a merge otherwise would emit a "note:
>>> using X as ancestor of X and X" message.
>>>
>>> See http://mercurial.selenic.com/wiki/BidMerge for an updated online
>>> description of what it is.
>> Very nice! This makes my answer here obsolete in Mercurial 3.0:
>>
>>    http://stackoverflow.com/a/9430810/110204
>
> Yes - I implemented it because that dude and his co-workers need it ;-)

You're awesome! :)

> For the record: The things you point out here is for user controlled
> manual ancestor selection. Bid merge is about automatically using all
> of them.

I see how bid merge is a superset of the functionality in the little
extension I wrote the answer.

> How can we make bid merge work better for the case you give?

I think it's pretty good -- adding a real --ancestor command line flag
to merge would make it a little easier to discover this feature. But I
take it that you want to keep this feature a little under the radar for
now.

>>    $ hg merge
>>    note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
>>          alternatively, use --config merge.preferancestor=fdf4b78f5292
>>          alternatively, use --config merge.preferancestor=30c60e28aa9b
>>          alternatively, use --config merge.preferancestor=a63958bcf63a
>>    merging x
>>    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
>>    (branch merge, don't forget to commit)
>
> We did a bit of bike shedding. It can probably take another layer of
> paint - feel free to propose a patch ;-)
>
> I used the unusual indentation to make it more clear that it was a
> single multi line note, not a part of the progress info shown on the
> following lines.

Yes, that does make some sense :) You basically have a multi-line note
where the second and following lines are optional. From a translation
point of view that's not optimal: translators love to get full sentences
with full context.

>> For a single alternative, I would suggest using the normal hint style:
>>
>>    $ hg merge
>>    note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
>>    (alternatively, use --config merge.preferancestor=fdf4b78f5292)
>>    merging x
>
> Are hints normal for notes (which in this case actually is a status
> message)?

No, they're actually not normal... we only have hints when we abort the
execution by raising util.Abort.

>> When there are multiple alternatives, I will argue that listing them
>> isn't super helpful: I think the kind of user who want this
>> information and who will know what to do with it will want to inspect
>> the ancestors before proceeding.
>
> I disagree. The kind of user who need it is the ordinary user who for
> some reason ends up in an unfortunate situation. It might even more
> often be the more novice users who have a messy history and don't know
> how to use version control efficiently.

It's just a guess, but I think these messages will confuse many users.
We're both power users and I don't know how I should react to these
messages -- why would I want to pick one over the other ancestor? Can I
somehow evaluate the quality of the ancestors?

>> So my suggestion would be to instead include the log command needed
>> to see the ancestors. Something like:
>>
>>    $ hg merge
>>    note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
>>    (use 'hg log -r "heads(::333411d2f751 and ::7d1f71140c74)"' to
>> see them all)
>>    merging x
>>    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
>>    (branch merge, don't forget to commit)
>
> Why should we show a scary revset to the user and ask him to run it?
> Why not just run it and give the user the info he can use?

Because I feel that we don't know what information the users really
needs. Listing the changeset IDs is not enough for me to decide which
ancestor to use -- I think I'll need to go lookup the ancestors somehow?

Maybe I'm wrong, maybe you expect users to retry the merge with the
other ancestor and see what happens?

As a curious users, I would probably do that. In that case, it would be
helpful if Mercurial could already tell me if the merge result would
differ depending on which ancestor I pick. In my criss-cross merge
example above, the merge result was different depending on the ancestor
chosen -- that's important information.

> 2 ancestors will happen more rarely than 2 ancestors. I think it is
> important that they use the same message and don't look like something
> different. I do not think it matters that the message looks a bit
> inelegant and funny if just it is clear. I would suggest just
> repeating the "(alternatively, ...)" messages.

You're right that this case wont be so common.

>> That's still a bit long and unhelpful -- people would still need to
>> know why they might want to pick another merge base. Maybe an even
>> better idea would be to refer people to a help topic. We could add a
>> verbose section to 'hg help merge' that describes this, for example.
>>
>> I think the feature is undocumented right now -- I can add a
>> paragraph to 'hg help merge' and config.txt if people like that idea?
>
> Thanks, that could perhaps be helpful.
>
> Users should however never add it to their hgrc so describing it in
> config.txt could be misleading.
>
> The option should only be used after an ordinary merge has shown the
> ambiguity and suggested some values. Most users will probably never
> see it. It should thus not take too much attention for people reading
> the help.

So maybe a verbose section in 'hg help merge' is better. I would then
prefer a hint-like message of the form

  $ hg merge
  note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
  (alternatives: fdf4b78f5292, 30c60e28aa9b, see 'hg help -v merge')

> Note: Bid merge has not seen a lot of testing and feedback. It could
> be considered kind of experimental and is so far not documented.

Yeah, the full power of this is still experimental. But I think the
notes (potentally) printed by 'hg merge' make the feature quite public.
That means that we should come up with some documentation.

-- 
Martin Geisler
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140422/a68243c8/attachment.pgp>