Better merge tool integration

[Martin Pool]

On 1 July 2010 12:46, Gordon Tyler <gordon.tyler at gmail.com> wrote:

> On 6/30/2010 9:10 PM, Martin Pool wrote:
>>> 1. Create a mergetools module in bzrlib which provides an API for
>>> configuring and invoking external merge tools.
>>
>> Maybe there should be some commonality with other external tools
>> (editors, diff, etc).  But it may be better to do the specific case of
>> merge first.
>
> Agreed on both counts.
>
>>> 2. Add 'bzr' commands for configuring and invoking the tools.
>>
>> Can you tell us more about this?
>
> I haven't actually given a lot of thought to the bzr commands yet since
> I was coming at this from the qconflicts viewpoint. I had a vague idea
> of an 'extmerge' command much like the bzr-extmerge plugin. Also, a
> command to add or update a merge tool and a command to remove a merge
> tool. Suggestions of good names for these commands and how to structure
> them and their options would be appreciated. I was thinking merge tools
> would be identified by the basename of their executable.

I think the layers are:

 - commands that cause a tool to run
 - api for running/checking/etc tools
 - model for configuring the tools
 - commands for configuring that model

So you want to model both a set of configuration options that control
tools, and perhaps also a ui to set them if editing the config file is
not enough.  istm that just editing it may be enough to start with.

>> I think the configuration should go into the generic config framework.
>
> Agreed. I am loading it as a list of commandlines from the global bzr
> config, i.e. GlobalConfig().get_user_option_as_list().

I think eventually this wants to be taken from the per-location configuration.

We might have some tools that merge whole trees and some that merge
just individual files.  For the latter you might like to use file
categories (I think that's the name) to indirectly say that xml files
should merge using blah.

>
> However, the actual UI for configuring can go a little further than just
> a simple list of command lines. The MergeTool object from the mergetools
> module allows the UI to extract/update the executable for
> display/editing in a separate field from the arguments. The
> is_available() indicator allows the UI to show (somehow) that the tool
> is usable without further configuration and also to filter the list of
> invokable tools to only those that are actually usable.
>
> I have also provided a toplevel list of help texts for each substitution
> marker, for use in the UI.
>
>>> 3. Modify qconflicts to use the mergetools module for invoking the tools.
>>> 4. Modify qconfig to use the mergetools module for configuring the tools.
>>
>> .. and also regular command-line merge, remerge, conflicts, etc?
>
> I thought that a separate command to invoke the external merge would be
> the right way to do it. Do you have a different suggestion?

I think 'merge --tool kmerge' or perhaps the user will even want to
set a default merge tool for particular situations.

-- 
Martin