[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/22/2014 10:05 AM, Martin Geisler wrote:
>> 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.

Yes. But it should also add it to graft and rebase and update and 
backout ... and everything that uses revsets.

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

I think it primarily will make the user wonder. The user will be alert 
and think about what is going on ... and hopefully deal with it, no 
matter if he has full or limited understanding of the situation.

I will reserve the word "confuse" to situations where the tool gives 
vague or misleading hints without helping the user to understand or deal 
with the situation.

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

I don't think we can say anything beyond "you can try the alternative, 
and if you like that better, use it".

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

The only way you can decide is to try them (which pretty much is what 
bid merge do). All the info you need to try a different ancestor is the 
--config syntax and the revision hash.

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

That would in many situations be the recommended action, yes.

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

I think most cases either will be simple (where the first try is 
completely smoorth) so the user won't retry, or it will be complex and 
it probably will make a difference. Whether it makes a real difference 
or not depends on the details of the conflict and the merge tool.

Again, this is something bid merge try to automate.

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

That could work. But I think it is valuable to give the user exactly the 
information he needs (ie the config syntax and name).

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

Yes, preferancestor is public. And no, the hints do not mention "*" and 
bidmerge.

/Mads