patchmergetool: add support for ECMerge

This commit adds a mechanism to provide absolute paths to the commands called by 'git mergetool'. A path can be specified in the configuation variable merge.<toolname>path.

This mechanism is especially useful on Windows, where external programs are unlikely to be in the path.

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Documentation/git-mergetool.txt |    5 ++
 git-mergetool.sh                |   81 ++++++++++++++++++++++-----------------
 2 files changed, 51 insertions(+), 35 deletions(-)

Add support for ECMerge available from http://www.elliecomputing.com/Products/merge_overview.asp

Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
 Documentation/git-mergetool.txt |    2 +-
 git-mergetool.sh                |   12 +++++++++++-
 2 files changed, 12 insertions(+), 2 deletions(-)

On Mon, Oct 08, 2007 at 11:22:41PM +0200, Steffen Prohaska wrote:

Hmm.  A propietary merge tool.  It's not that much code, so I guess....

I note though that it claims on the web page that they are integrated with "most famous SCM's", but they don't include git. If we add this support, are they going to change their web page? :-)

Also, ECmerge is supported on Linux, Solaris, MacOS X, and Windows. Which platforms have you tested on? My guess is that if it works on Linux, it'll probably work on Solaris and MacOS, but is it a fair guess you haven't tested under Windows? Not that most Windows systems are going to be able to use git-mergetool since it's a bash script, unless they are using Cygwin or some such.

       	    	      	     	     - Ted

On Oct 8, 2007, at 11:44 PM, Theodore Tso wrote:

You may even apply for a free (as beer) license if you contribute to open source projects:

http://www.elliecomputing.com/Community/opensource.asp

I didn't try this, so I can't say how this works in practice.

Windows. Haven't tested Unix systems yet.

I work on the msysgit project and I'd like to have mergetool available before I advertise git on Windows. It makes merging so much easier ;)

	Steffen

Hi,

On Tue, 9 Oct 2007, Steffen Prohaska wrote:

I would _hate_ to rely on a closed source program (in addition to Windows itself) in msysGit.

And it seems that you cannot even get ECMerge for free in general.

What does TortoiseCVS use?

Ciao, Dscho

On Oct 9, 2007, at 2:37 PM, Johannes Schindelin wrote:

It's only an option. You can also choose kdiff3 if you like, or vimdiff or emacs merge. But personally, I prefer ECMerge because is seems to support a faster and safer workflow (at least for me).

Before submitted this patch I thought about a general mechanism to easily specify any tool that supports command line argument. But just adding them tool by tool as needed looks easier to me, and hopefully to the user. We can include the correct command line in git-mergetool and only require the location of the program from the user.

True. But does it matter? I can't get Windows for free and git runs on it.

Don't know.

	Steffen

On 10/9/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

They don't actually include it in the package, but they recommend WinMerge http://winmerge.org/, which is free (GPL).

On Oct 9, 2007, at 3:03 PM, Alan Hadsell wrote:

WinMerge doesn't support 3-way merges. At least I cannot find any indication for 3-way in the manual [1] and the comparison at [2] also tells that WinMerge doesn't support 3-way.

	Steffen

[1] http://winmerge.org/2.6/manual/CompareFiles.html [2] http://en.wikipedia.org/wiki/Comparison_of_file_comparison_tools

Steffen Prohaska writes:

Does WinMerge support merging three files? Sometimes it is called 3-way merge, where one file is ancestor. This would be useful for version control!

Unfortunately not. We acknowledge it would be good feature but have no plans to implement it in near future. This can be somewhat worked around by using two WinMerge instances. (One developer has begun preliminary work on this feature, but it is not yet available, even in experimental releases.)

On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:

This patch doesn't work the config file doesn't specify an explicit mergetool via merge.tool. The reason for that is this loop:

    for i in $merge_tool_candidates; do
        if test $i = emerge ; then
            cmd=emacs
        else
            cmd=$i
        fi
        if type $cmd > /dev/null 2>&1; then
            merge_tool=$i
            break
        fi
    done

is only checking to see if $cmd is in the path; it's not looking up the merge.<toolname>path variable in this loop.

I guess the other question is whether we would be better off simply telling the user to specify an absolute pathname in merge.tool, and then having git-mergetool strip off the directory path via basename, and then on window systems, stripping off the .EXE or .COM suffix, and then downcasing the name so that something like "C:\Program Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be right in guessing that the reason why you used merge.<toolname>path approach was to avoid this messy headache?

					- Ted

On Mon, Oct 08, 2007 at 05:57:29PM -0400, Theodore Tso wrote:

Err, let me try that again. "This patch doesn't work IF the config file doesn't specify an explicit > mergetool via merge.tool."

Sorry about the missing conjuction; the sentence doesn't make much sense without it...

						- Ted

On Oct 8, 2007, at 11:57 PM, Theodore Tso wrote:

I didn't change the automatic detection. It should work as before. That is it continues to assume that merge tools are in PATH.

Is you expectation that git-mergetool should also consider the absolute paths provided in merge.<toolname>path?

When I wrote the patch I had in mind that people will set the merge.tool explicitly if they provide an absolute path. Automatic detection would only be used if nothing is configured. In this case a tool must be in PATH or would not be found.

Yes. The program to start ECMerge on Windows is called 'guimerge.exe'. Hard to derive a sensible short name from this.

So I don't think that an automatic translation is an option. I prefer to provide the absolute paths.

Absolute paths have another advantage. You can set several of them and choose a tool on the command line. Maybe you have several tools you want to try. Or you hacking with someone else who preferes a different tool. Or you just want to give a demo. I see merge.<toolname>path more as a database associating absolute paths with the shortnames.

My mental model is as follows:
1) merge.tool selects the mechanism needed to call the tool, that is
command line arguments, how merge result is passed, ...
2) merge.<toolname>path provides additional information how to locate
the selected tool in the filesystem.

The two points are somewhat orthogonal. I'd not fuse them into one.

	Steffen

On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:

Why not merge.<toolname>.path? This would it make easy to introduce new variables of the form merge.<toolname>.<var> later if needed. I also think it is more consistent with names of existing configuration variables. (think branch.<name>.<var> or remote.<name>.<var>)

Gruesse,

On Oct 9, 2007, at 12:00 AM, Frank Lichtenheld wrote:

Looks more beautiful on the command line but a bit more complex in the config file. But I like the idea.

Maybe mergetool.<tool>.path is even a better choice? It clearly indicate the relationship with mergetool. We could explain:

'The variable merge.tool = <tool> refers to a tool that can be further specified in mergetool.<tool>.path.'

	Steffen

Hi,

On Mon, 8 Oct 2007, Steffen Prohaska wrote:

Would it not be more in line with all other config variables if it was written merge.<toolname>.path? (Indeed, I thought your subject line contained a typo when I read it first.)

Ciao, Dscho