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

[Mads Kiilerich]

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 ;-)

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.

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

> By the way, I think the message format is a little verbose and unusual
> here:
>
>    $ hg merge
>    note: using eb49ad46fd72 as ancestor of 333411d2f751 and 7d1f71140c74
>          alternatively, use --config merge.preferancestor=fdf4b78f5292
>    merging x
>    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
>    (branch merge, don't forget to commit)
>
> The hanging indentation looks unusual to my eyes. The hint is repeated
> if there are multiple alternative ancestors and I think that looks even
> more funny:
>
>    $ 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.

> 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)?

> 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.

> 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?

 >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.

> 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.

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.

/Mads