threads / patch / 19154

patchmergetool--lib: specialize diff options for emerge and ecmerge

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

## tl;dr

7 messages between May 2, 2009 and May 3, 2009. Diffs are folded; open one to read it.

replies: 6people: 3as markdown or json

David Aguilar· May 2, 2009, 08:57 UTC · lore
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(-)
Show changes to git-mergetool--lib.sh +3 −3
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
David Aguilar· May 2, 2009, 19:46 UTC · re: David Aguilar · lore

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

On  0, David Aguilar <davvid@gmail.com> wrote:
Show 10 quoted lines
> 
> 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

Show 12 quoted lines
> 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
Markus Heidelberg· May 3, 2009, 06:27 UTC · re: David Aguilar · lore

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

David Aguilar, 02.05.2009:
Show 7 quoted lines
> 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
David Aguilar· May 3, 2009, 18:21 UTC · re: Markus Heidelberg · lore

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

Markus Heidelberg <markus.heidelberg@web.de> wrote:
Show 12 quoted lines
> 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
Markus Heidelberg· May 3, 2009, 19:12 UTC · re: David Aguilar · lore

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

David Aguilar, 03.05.2009:
Show 16 quoted lines
> 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.

Show 7 quoted lines
> 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.
David Aguilar· May 3, 2009, 20:34 UTC · re: Markus Heidelberg · lore

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

Markus Heidelberg <markus.heidelberg@web.de> wrote:
Show 6 quoted lines
> > 
> > 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 :)
Show 6 quoted lines
> > 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
Marcin Zalewski· May 3, 2009, 18:47 UTC · re: David Aguilar · lore

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

David,
Thanks for your patches.
Show 9 quoted lines
> 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

← back to recent threads