Problems with default value of merge tool

[Pierre-Yves David]

On 11/24/2015 10:56 PM, Steve (Gadget) Barnes wrote:
>
>
> On 25/11/2015 00:12, Pierre-Yves David wrote:
>>
>>
>> On 11/24/2015 03:02 PM, Augie Fackler wrote:
>>>
>>>> On Nov 23, 2015, at 1:17 PM, Pierre-Yves David
>>>> <pierre-yves.david at ens-lyon.org> wrote:
>>>>
>>>>
>>>>
>>>> On 11/23/2015 09:36 AM, Augie Fackler wrote:
>>>>>
>>>>>> On Nov 13, 2015, at 5:12 PM, Pierre-Yves David
>>>>>> <pierre-yves.david at ens-lyon.org> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/12/2015 11:49 AM, Matt Mackall wrote:
>>>>>>> On Thu, 2015-11-12 at 12:15 +0000, Alan Mackenzie wrote:
>>>>>>>> Hello, Mercurial.
>>>>>>>>
>>>>>>>> I'm running Mercurial 3.3.2 on Gentoo GNU/Linux.
>>>>>>>>
>>>>>>>> Last night I had an unpleasant experience with hg.  On doing an hg
>>>>>>>> graft, there were merge conflicts, and hg opened some angry fruit
>>>>>>>> salad
>>>>>>>> merging tool.
>>>>>>>>
>>>>>>>> I wasn't familiar with this tool, and in fact, I don't even know
>>>>>>>> what
>>>>>>>> it
>>>>>>>> was.  By experimentation, I managed to get out of it typing ":q"
>>>>>>>> (three
>>>>>>>> times).  I think hg then asked me if the merge had been successful,
>>>>>>>> and
>>>>>>>> I said "no".
>>>>>>>
>>>>>>> Welcome to vimdiff. I hate vim and vimdiff too, but as you've
>>>>>>> probably
>>>>>>> already read, some people love it. Which means that if we disable
>>>>>>> it by
>>>>>>> default, we will make people who've already configured their
>>>>>>> environment to their liking have a bad day. Breaking one set of
>>>>>>> users'
>>>>>>> configs to make another set happy is not the sort of trade-off we
>>>>>>> like
>>>>>>> to make.
>>>>>>
>>>>>> I remember a discussion with Mads Kiilerich where we concluded that
>>>>>> we should probably not have an actual default merge tools (because
>>>>>> it is almost alway providing a confusing result for users).
>>>>>>
>>>>>> The idea would be to have a default merge tool that display
>>>>>> available choice and prompt the user to configure one he is
>>>>>> comfortable with. This issue is coming up frequently enough that we
>>>>>> should probably make it happen. I wonder what other people think.
>>>>>
>>>>> This sounds like an improvement over the unredeemable experience
>>>>> that is the status quo.
>>>>>
>>>>> (I feel like this is coming up more often now than it used to, and
>>>>> as such I feel like we should try a bit harder to figure out a happy
>>>>> path forward for people that don’t want to (or can’t) forcibly
>>>>> excise vim(diff) from their system.
>>>>
>>>> I think that the next step here is to create a MergeToolsPlan on the
>>>> Wiki to summaries the issue and current leads so that we can converge
>>>> toward a solution to implement.
>>>>
>>>> If someone interested in that topic whats to do that create such
>>>> page, that would be nice :)
>>>
>>> https://www.mercurial-scm.org/wiki/MergeToolsPlan started. Please feel
>>> encouraged to contribute.
>>
>> Nice jobs, I've further idea on the topic, but I'm not yet sure how to
>> include them in the page. I'll dump them in the email for now.
>>
>> 1) We should behave properly if the merge in non-interactive.
>> -------------------------------------------------------------
>>
>> I'm not sure what we currently do in that case but I'm assuming we use
>> internal:merge and move forward. We should keep (get to) that behavior
>> in the future.
>>
>>
>> 2) Prompt display
>> -----------------
>>
>> The list of Mercurial tool will be long and complicate.  I think it is
>> still worthwhile to inflict it to the user (better than vimdiff). I
>> think we should have a multiple line prompt (exceptional situation!)
>>
>> There are merge conflicts in file ./some/path/to/filename.ext, but no
>> default merge tool has been defined in ui.merge, please pick one:
>>
>> ?) get more help and details
>> f) fail the merge and go back to the command line
>> 0) merge (leave merge marker in your repository)
>> 1) merge3 (same, also display content from the base)
>> 0) kdiff3
>> 1) meld
>> 2) vimdiff
>> o) See other unavailable merge tool
>>
>> (content of form provided as exemple)
>>
>> 3) Transition for current user
>> ------------------------------
>>
>>> Some users might intentional not have configured a [ui]merge=$TOOL
>>> intentionally and expect the current behavior of using the "best" tool
>>> that's installed
>>
>> The choices should probably be order used the current priority that way
>> people who expect the default to be the best would have the "best" as
>> default prompt choice.
>>
>> 4) Helping people to pick
>> -------------------------
>>
>> Picking a a merge tool will be complicated and stressful for most user,
>> we should probably:
>>
>> - Have a description of each configurer merge tool in the config (that
>> user can access from the prompt)
>>
>> - Easy way to see what other option exist for there system and how to
>> gain access to it if not already available.
 >
> It might also be worth offering a list of potential downloads of
> 'recommended' free merge tools, Windows users especially are short
> decent of pre-installed tools.
 >

+0.5 this is the kind of stuff I was entailing in "how to gain access to 
it if not already available." best way to do that is probably to be 
ironed out.

>> 5) saving the config change
>> ---------------------------
>>
>> We should probably make it possible to save the result of that merge in
>> user config. Adding the config at the end of the user/repo HGRC seems
>> the way to go.
>>
>> Having a post-merge prompt asking:
>>
>> Do you want to use this merge tool in the future
>> - no, ask me again next time,
>> - yes for all merge in this repository,
>> - yes for all my merge,
>>
 >
> The more common pattern is to offer to use the selected tool this time
> only or every time at the selection time rather than post merge - this
> makes the process, !select->decide if default->do merge! rather than
> "select->do merge->decide if default" which seems a little disjointed.
 >

I expect most user to have low amount of idea of what they are doing and 
picking. Asking the question "after" will help them to answer the 
question from their experience in the last minute:
1) That was nice, let's use it next time
2) That was awful, never again!

-- 
Pierre-Yves David