Re: [PATCH 3/3] mergetool--lib: Add the proper executable name for ECMerge

From: Chris Packham <judge.packham@gmail.com>
Date: Feb 27, 2011, 19:25 UTC
Message-ID: <4D6AA513.1050002@gmail.com>
In-Reply-To: <AANLkTi=CuyNLNuuootcd8_H9Zh=WqAwiS+S6PJjPAfcw@mail.gmail.com>

On 27/02/11 23:37, Sebastian Schuberth wrote:

Show 29 quoted lines

> On Sun, Feb 27, 2011 at 06:50, Chris Packham <judge.packham@gmail.com> wrote:
> 
>>> +     ecmerge)
>>> +             echo guimerge
>>> +             ;;
>>>       emerge)
>>>               echo emacs
>>>               ;;
>>
>> I think this is another case of linux/windows versions of the
>> application having different executable names.
>>
>> chrisp@laptop:~> tar -tf Download/ecmerge-2.3.123.linux.x86.tbz
>> /usr/local/bin/ecmerge
>> /opt/elliecomputing/ecmerge/guimerge
>> /opt/elliecomputing/ecmerge/guimerge.exe
> 
> Indeed, well except that Linux has both "ecmerge" and "guimerge",
> whereas Windows only has "guimerge", which is why I went with the
> latter. Giving it a second thought, my patch is a little inconvenient
> for Linux users, as it will stop making ecmerge work out of the box
> (without first setting mergetool.ecmerge.path), whereas Windows users
> need to set mergetool.ecmerge.path anyway.
> 
> I've also contacted the makers of ECMerge and asked them to unify the
> naming across platforms. Maybe we should just drop this patch until
> they did.
> 
> Chris, what do you think?

If the ecmerge makers can get 'ecmerge' to be a valid command on windows then that'd be the best solution for now.

I have a different idea for handling this going forward (maybe for v1.8.0). One benefit of having built-in knowledge of a mergetool, as opposed to using config variables, is git knows when to do a 2-way merge vs a 3-way merge. So instead of having a single mergetool.cmd maybe we need mergetool.cmd2way and mergetool.cmd3way, all of the existing supported mergetools could then be expressed as a set of config variables (maybe installed in system or global configs by the git installation process).

I'll try to write that up as a proper v1.8.0 proposal when I get a chance.