Re: Choosing a mergetool according to file type

Hi Johannes,

On 2009-06-26 11:43, "Johannes Sixt" <j.sixt@viscovery.net> wrote:

OK, that was my impression, but I wanted to check.

 > The reason I write to you is: Can you tell me what 'wordgitmerge' and

Ah! Well they are nothing fancy, I'm afraid, just scripts that call Word itself, but that turns out to work pretty well. For Mac (my platform) they have to be in applescript. For Windows I imagine they could be pretty much the same as the scripts here:

http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/contrib/diff-scripts/

diff-doc.js merge-doc.js

Perhaps tortoisegit already exposes this. Those scripts include fallbacks for openoffice so I suppose one could use that on linux.

Best,

Greg.

Gregory Jefferis schrieb:

Thanks a lot for the pointer.

The interesting one is merge-doc.js. Unfortunately, it still only just compares "their" and "our" versions, and the user must go through all marked changes and reject everything that would undo "our" changes and accept all "their" changes. That's exactly what I already do. :-(

That said, the scripts are written *much* nicer than what I have written myself.

-- Hannes

Gregory Jefferis <jefferis@gmail.com> writes:

Never used it, but man gitattributes says

   Performing a three-way merge
       merge
[...]
              String
                 3-way merge is performed using the specified custom merge driver. The built-in 3-way merge driver can be explicitly specified by asking
                 for "text" driver; the built-in "take the current branch" driver can be requested with "binary".
[...]
       Defining a custom merge driver

Is it not what you're looking for?

Hi Matthieu,

Thanks for your reply.

On 2009-06-26 13:04, "Matthieu Moy" <Matthieu.Moy@imag.fr> wrote:

This defines the merge driver but not the mergetool. A mergetool is presumably an interactive tool that helps you clean up failed automatic merges. For my binary files the internal merge driver "binary" will be used which as your quote points our keeps the local file and signals a conflict if it is different from the remote file. I cannot define a custom merge driver for my binary word files because I don't have such a program (which would have to carry out the merge in a non-interactive fashion). As mergetool I use a script that calls Word and that of course has to be interactive.

Best,

Greg.

Gregory Jefferis <jefferis@gmail.com> writes:

This is why I quoted the title of the section

Just tried it with 

[merge "filfre"]
       name = feel-free merge driver
       driver = gedit %O %A %B
       recursive = binary

It did launch gedit interactively during the merge.

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

You are both correct. Your example runs "gedit" with three files before merge. If Gregory's custom mergetool expects the failed half-merge result as its input, this is not the interface he is looking for.

It shouldn't be hard to teach mergetool/difftool wrapper to support the per-path tool selection by running "git check-attr".

Right now it uses "diff.tool" and "merge.tool" configuration variables. In addition, it can arrange to consult "mergetool.$type.diff" and "mergetool.$type.merge". These new two variables will override the existing ones that are now treated as type-agnostic default.

IOW, something like this.

(1) In .gitattributes, define files whose name end with js is of type
    gjefferis in the mergetool namespace:

	*.js	mergetool=gjefferis

(2) In .git/config, define that gjefferis type is handled by diff-doc.js
    and merge-doc.js

    [mergetool "gjefferis"]
	diff = diff-doc.js
        merge = merge-doc.js

(3) Enhance get_configured_merge_tool() in git-mergetool--lib.sh and
    callchain that leads to it.

    type=$(git checkattr mergetool -- $file)
    if test -n "$type"
    then
    	mergetool=$(git config mergetool.$type.merge)
        difftool=$(git config mergetool.$type.diff)
    else
        mergetool=$(git config merge.tool)
        difftool=$(git config diff.tool)
    fi

It appears that right now the function does not know what file it is dealing with, so you may need to first restructure the callchain a bit, but it shouldn't be too painful.

On 2009-06-26 17:57, "Junio C Hamano" <gitster@pobox.com> wrote:

I think that Matthieu is more correct this time in that I can do what I need with the merge driver because I don't need the failed half-merge result. But I prefer the 2 level arrangement of 1) automatic then 2) fixing merge conflicts manually since there will be other cases where this is required.

Thank you Junio for pointing out how to do add the necessary functionality - a project for a rainy weekend I guess.

Best,

Greg.

Hi Matthieu,

On 2009-06-26 14:51, "Matthieu Moy" <Matthieu.Moy@imag.fr> wrote:

Hmm, I had of course looked at this but this thought that it wouldn't do what I want. For one, I thought this would _always_ call gedit even if the file is unchanged in remote. Testing, however this doesn't seem to be the case. So I think you're right that this method can be used satisfactorily even with an interactive merge and I have made a little script that seems to do what I need.

On the other hand to me it does somewhat violate the separation between automatic and interactive merging and one probably has to be quite careful about what state the merge files are left in - presumably things that whoever wrote the builtin "binary" merge thought about carefully.

All the best,

Greg.