[PATCH] mergetool--lib: specialize diff options for emerge and ecmerge

The ecmerge documentation mentions the following form:

	ecmerge --mode=diff2 $1 $2

Since git-difftool is about diffing, we should use that
instead of --mode=merge2.  Likewise, this drops the
$MERGED argument to emerge, as discussed on the git list
($gmane/117930).

Signed-off-by: David Aguilar <redacted>
---

I tested the emacs (emerge) bit, but I'm not an emacs
user and I didn't really see any difference with or
without the patch.  Dropping $MERGED seems like the
right thing to do nonetheless.

In emerge/emacs mode, we still end up seeing the
merge pane.  My emacs-fu is not sophisticated
enough to know how to inhibit the merge pane
(if that's even something we'd want to do).


Regarding ecmerge:  I found the --mode=diff2
flag by reading their documenation:

http://www.elliecomputing.com/OnlineDoc/ecmerge_EN/52335623.asp

I don't have ecmerge installed at all, so I'm just
going by the book on this one.  It *looks* correct,
and probably is, but let it be known that I
haven't tested the ecmerge snippet myself.

 git-mergetool--lib.sh |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index a16a279..8b5e6a8 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh

@@ -228,8 +228,8 @@ run_merge_tool () {
 			fi
 			check_unchanged
 		else
-			"$merge_tool_path" "$LOCAL" "$REMOTE" \
-				--default --mode=merge2 --to="$MERGED"
+			"$merge_tool_path" --default --mode=diff2 \
+				"$LOCAL" "$REMOTE"
 		fi
 		;;
 	emerge)

@@ -248,7 +248,7 @@ run_merge_tool () {
 			status=$?
 		else
 			"$merge_tool_path" -f emerge-files-command \
-				"$LOCAL" "$REMOTE" "$(basename "$MERGED")"
+				"$LOCAL" "$REMOTE"
 		fi
 		;;
 	tortoisemerge)

-- 
1.6.3.rc3.40.g75b44

On  0, David Aguilar [off-list ref] wrote:

Regarding ecmerge:  I found the --mode=diff2
flag by reading their documenation:

http://www.elliecomputing.com/OnlineDoc/ecmerge_EN/52335623.asp

I don't have ecmerge installed at all, so I'm just
going by the book on this one.  It *looks* correct,
and probably is, but let it be known that I
haven't tested the ecmerge snippet myself.

I installed ecmerge on a mac today and gave this a try.
ecmerge is indeed better with this patch.

After configuring the path it all "just works":

$ git config --global mergetool.ecmerge.path \
	/Applications/ECMerge.app/Contents/MacOS/guimerge

We now get a simple side-by-side diff without the
merge pane at the bottom of the screen.  Nice.


If an emacs user could comment on the emerge snippet
below (or perhaps suggest a better one ;)) then that
would make me happy.  As is, I have tested the
emacs emerge snippet and it works, but I'm not
sure if that's enough to resolve the issue reported
by Marcin.  Marcin?

Here's the original thread:
http://article.gmane.org/gmane.comp.version-control.git/117930

-- 
		David

David Aguilar, 02.05.2009:

I installed ecmerge on a mac today and gave this a try.
ecmerge is indeed better with this patch.

After configuring the path it all "just works":

$ git config --global mergetool.ecmerge.path \
	/Applications/ECMerge.app/Contents/MacOS/guimerge

Would it make sense to set merge_tool_path to guimerge by default then?

Markus

Markus Heidelberg [off-list ref] wrote:

David Aguilar, 02.05.2009:

quoted

I installed ecmerge on a mac today and gave this a try.
ecmerge is indeed better with this patch.

After configuring the path it all "just works":

$ git config --global mergetool.ecmerge.path \
	/Applications/ECMerge.app/Contents/MacOS/guimerge

Would it make sense to set merge_tool_path to guimerge by default then?

Markus

On Linux, ecmerge is "ecmerge".
Macs are weird.  Windows--even worse.

We could test $(uname) = "Darwin" and do the user-friendly thing by default,
but that might not be a good idea.  The user-friendly thing is actually
"/Applications/...lots.of.stuff.../guimerge", and that's a lot more
platform-specific than just "guimerge".

The usability fairy says we should be nice to users and turn
translate_merge_tool_path() into a massive platform-specific 
hack.  The lazy person in me would rather list the tweaks
on the git wiki and silently reward linux users since
the defaults work fine there as-is.

What do you think?

-- 
		David

David,

Thanks for your patches.

If an emacs user could comment on the emerge snippet
below (or perhaps suggest a better one ;)) then that
would make me happy.  As is, I have tested the
emacs emerge snippet and it works, but I'm not
sure if that's enough to resolve the issue reported
by Marcin.  Marcin?

Here's the original thread:
http://article.gmane.org/gmane.comp.version-control.git/117930

As far as I am concerned, this patch works well. Without the third
argument, ediff will not complain anymore that it is "too dangerous to
merge versions of a file visited by another buffer," which was my
original problem.

-Marcin

David Aguilar, 03.05.2009:

Markus Heidelberg [off-list ref] wrote:

quoted

David Aguilar, 02.05.2009:

quoted

I installed ecmerge on a mac today and gave this a try.
ecmerge is indeed better with this patch.

After configuring the path it all "just works":

$ git config --global mergetool.ecmerge.path \
	/Applications/ECMerge.app/Contents/MacOS/guimerge

Would it make sense to set merge_tool_path to guimerge by default then?

Markus

On Linux, ecmerge is "ecmerge".
Macs are weird.  Windows--even worse.

And the ecmerge developers are even more worse or is there a reason to
have different names for the binaries?

We could test $(uname) = "Darwin" and do the user-friendly thing by default,
but that might not be a good idea.

Or use "type" there already to test whether guimerge exists, else
default to ecmerge.

The user-friendly thing is actually
"/Applications/...lots.of.stuff.../guimerge", and that's a lot more
platform-specific than just "guimerge".

Why is the whole path more user friendly, because of guimerge not being
in PATH? Is the /Applications/... directory always the same for ecmerge
for each Mac user? But we don't care in other diff/merge tools about the
exact location and I think we shouldn't begin it here.

The usability fairy says we should be nice to users and turn
translate_merge_tool_path() into a massive platform-specific 
hack.  The lazy person in me would rather list the tweaks
on the git wiki and silently reward linux users since
the defaults work fine there as-is.

What do you think?

Not sure, leaving it as is is still an option.

Markus Heidelberg [off-list ref] wrote:

quoted

On Linux, ecmerge is "ecmerge".
Macs are weird.  Windows--even worse.

And the ecmerge developers are even more worse or is there a reason to
have different names for the binaries?

But of course :)

quoted

The user-friendly thing is actually
"/Applications/...lots.of.stuff.../guimerge", and that's a lot more
platform-specific than just "guimerge".

Why is the whole path more user friendly, because of guimerge not being
in PATH? Is the /Applications/... directory always the same for ecmerge

Yup.

for each Mac user? But we don't care in other diff/merge tools about the
exact location and I think we shouldn't begin it here.

Ditto.

quoted

What do you think?

Not sure, leaving it as is is still an option.

I agree.  So the original patch for ecmerge + emerge should be
good then. I still need to reroll the araxis patch after my bike
ride later.

-- 

	David