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

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

[David Aguilar]

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 <davvid@gmail.com>
---

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

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

[David Aguilar]

On  0, David Aguilar <davvid@gmail.com> 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


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

-- 
		David

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

[Markus Heidelberg]

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

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

[David Aguilar]

Markus Heidelberg <markus.heidelberg@web.de> wrote:
> 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

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

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

[Markus Heidelberg]

David Aguilar, 03.05.2009:
> Markus Heidelberg <markus.heidelberg@web.de> wrote:
> > 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
> 
> 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.

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

[David Aguilar]

Markus Heidelberg <markus.heidelberg@web.de> wrote:
> > 
> > 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 :)


> > 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.


> > 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

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

[Marcin Zalewski]

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