Re: [PATCH 7/7] mergetool--lib: Improve show_tool_help() output

John Keeping [off-list ref] writes:

quoted

quoted

It doesn't - the "|| continue" is to catch errors from setup_tool.

Ugh.

Is that targeted at my suggestion at the top of this email or calling
exit in setup_tool?

At the fact that you had to go a convoluted route because you cannot
just run setup_tool in subshell and do translate_merge_tool_path
after that, because the latter needs to look at the shell variable
the former sets.

With the patch above, the block of code at the top becomes:

 	test "$tool" = defaults && continue

 	setup_tool "$tool" 2>/dev/null || continue
 	merge_tool_path=$(translate_merge_tool_path "$tool")

which IMHO is pretty readable.

Of course it is.  The current callers of setup_tool may need some
adjustments, but that should be fairly trivial, I hope.

On Fri, Jan 25, 2013 at 01:47:59PM -0800, Junio C Hamano wrote:

John Keeping [off-list ref] writes:

quoted

With the patch above, the block of code at the top becomes:

 	test "$tool" = defaults && continue

 	setup_tool "$tool" 2>/dev/null || continue
 	merge_tool_path=$(translate_merge_tool_path "$tool")

which IMHO is pretty readable.

Of course it is.  The current callers of setup_tool may need some
adjustments, but that should be fairly trivial, I hope.

There are only two and one of them already seems like it doesn't want
the command to cause the script to exit.

David, can you incorporate the following two patches when you re-roll?
Your original 7/7 with the change above will want to build on 8/7.


John

This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.

Signed-off-by: John Keeping <redacted>
---
 git-mergetool--lib.sh | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 4c1e129..c6bd8ba 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh

@@ -67,11 +67,11 @@ setup_tool () {
 	if merge_mode && ! can_merge
 	then
 		echo "error: '$tool' can not be used to resolve merges" >&2
-		exit 1
+		return 1
 	elif diff_mode && ! can_diff
 	then
 		echo "error: '$tool' can only be used to resolve merges" >&2
-		exit 1
+		return 1
 	fi
 	return 0
 }

@@ -100,7 +100,7 @@ run_merge_tool () {
 	status=0
 
 	# Bring tool-specific functions into scope
-	setup_tool "$1"
+	setup_tool "$1" || return
 
 	if merge_mode
 	then

-- 
1.8.1

guess_merge_tool calls translate_merge_tool_path in order to get the
correct name of the tool to check whether it can be found on the user's
system.  But this function is designed to be overridden by tool
scriptlets so it does nothing if the relevant scriptlet has not been
sourced.

Fix this by calling setup_tool before doing anything.

Signed-off-by: John Keeping <redacted>
---
 git-mergetool--lib.sh | 1 +
 1 file changed, 1 insertion(+)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index c6bd8ba..46860c5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh

@@ -219,6 +219,7 @@ guess_merge_tool () {
 	# Loop over each candidate and stop when a valid merge tool is found.
 	for i in $tools
 	do
+		setup_tool "$i" 2>&1 || continue
 		merge_tool_path="$(translate_merge_tool_path "$i")"
 		if type "$merge_tool_path" >/dev/null 2>&1
 		then

-- 
1.8.1

Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
t7610 rather badly.

--- >8 ------ >8 ------ >8 ------ >8 ------ >8 ------ >8 ---

...
ok 1 - setup

expecting success:
    git checkout -b test1 branch1 &&
    git submodule update -N &&
    test_must_fail git merge master >/dev/null 2>&1 &&
    ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
    ( yes "" | git mergetool file1 file1 ) &&
    ( yes "" | git mergetool file2 "spaced name" >/dev/null 2>&1 ) &&
    ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
    ( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
    ( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
    ( yes "l" | git mergetool submod >/dev/null 2>&1 ) &&
    test "$(cat file1)" = "master updated" &&
    test "$(cat file2)" = "master new" &&
    test "$(cat subdir/file3)" = "master new sub" &&
    test "$(cat submod/bar)" = "branch1 submodule" &&
    git commit -m "branch1 resolved with mergetool"

M       submod
Switched to a new branch 'test1'
Submodule path 'submod': checked out '39c7f044ed2e6a9cebd5266529badd181c8762b5'
not ok - 2 custom mergetool
#
#           git checkout -b test1 branch1 &&
#           git submodule update -N &&
#           test_must_fail git merge master >/dev/null 2>&1 &&
#           ( yes "" | git mergetool both >/dev/null 2>&1 ) &&
#           ( yes "" | git mergetool file1 file1 ) &&
#           ( yes "" | git mergetool file2 "spaced name" >/dev/null 2>&1 ) &&
#           ( yes "" | git mergetool subdir/file3 >/dev/null 2>&1 ) &&
#           ( yes "d" | git mergetool file11 >/dev/null 2>&1 ) &&
#           ( yes "d" | git mergetool file12 >/dev/null 2>&1 ) &&
#           ( yes "l" | git mergetool submod >/dev/null 2>&1 ) &&
#           test "$(cat file1)" = "master updated" &&
#           test "$(cat file2)" = "master new" &&
#           test "$(cat subdir/file3)" = "master new sub" &&
#           test "$(cat submod/bar)" = "branch1 submodule" &&
#           git commit -m "branch1 resolved with mergetool"
#

--- 8< ------ 8< ------ 8< ------ 8< ------ 8< ------ 8< ---

Due to ">dev/null 2>&1", all of the error clues are hidden, and I
didn't dig further to see which one was failing (this is why tests
shouldn't do these in general).

On Fri, Jan 25, 2013 at 4:24 PM, Junio C Hamano [off-list ref] wrote:

Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
t7610 rather badly.

I just sent a replacement for the vim/symlink issue stuff.
I tried to keep the patch small.  John, can you rebase this
patch on top of it?

-- 
David

This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.

Signed-off-by: John Keeping <redacted>
---
On Fri, Jan 25, 2013 at 04:24:03PM -0800, Junio C Hamano wrote:

Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
t7610 rather badly.

Sorry about that.  The 'setup_tool' function should really be called
'setup_builtin_tool' - it isn't necessary when a custom mergetool is
configured and will return 1 when called with an argument that isn't a
builtin tool from $GIT_EXEC_PATH/mergetools.

The change is the second hunk below which now wraps the call to
setup_tool in an if block as well as adding the "|| return".

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

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 4c1e129..8a5eaff 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh

@@ -67,11 +67,11 @@ setup_tool () {
 	if merge_mode && ! can_merge
 	then
 		echo "error: '$tool' can not be used to resolve merges" >&2
-		exit 1
+		return 1
 	elif diff_mode && ! can_diff
 	then
 		echo "error: '$tool' can only be used to resolve merges" >&2
-		exit 1
+		return 1
 	fi
 	return 0
 }

@@ -100,7 +100,10 @@ run_merge_tool () {
 	status=0
 
 	# Bring tool-specific functions into scope
-	setup_tool "$1"
+	if test -z "$merge_tool_path"
+	then
+		setup_tool "$1" || return
+	fi
 
 	if merge_mode
 	then

-- 
1.8.1.1.367.ga9c3dd4.dirty

This will make it easier to use setup_tool in places where we expect
that the selected tool will not support the current mode.

We need to introduce a new return code for setup_tool to differentiate
between the case of "the selected tool is invalid" and "the selected
tool is not a built-in" since we must call setup_tool when a custom
'merge.<tool>.path' is configured for a built-in tool but avoid failing
when the configured tool is not a built-in.

Signed-off-by: John Keeping <redacted>
---

On Fri, Jan 25, 2013 at 04:24:03PM -0800, Junio C Hamano wrote:

quoted

Applying this one on top of 1/7 thru 5/7 and 7/7 seems to break
t7610 rather badly.

Sorry about that.  The 'setup_tool' function should really be called
'setup_builtin_tool' - it isn't necessary when a custom mergetool is
configured and will return 1 when called with an argument that isn't a
builtin tool from $GIT_EXEC_PATH/mergetools.

The change is the second hunk below which now wraps the call to
setup_tool in an if block as well as adding the "|| return".

Now that I've run the entire test suite, that still wasn't correct since
it did not correctly handle the case where the user overrides the path
for one of the built-in mergetools.

 git-mergetool--lib.sh | 23 ++++++++++++++++++++---
 1 file changed, 20 insertions(+), 3 deletions(-)

diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index 4c1e129..dd4f088 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh

@@ -58,7 +58,11 @@ setup_tool () {
 	. "$mergetools/defaults"
 	if ! test -f "$mergetools/$tool"
 	then
-		return 1
+		# Use a special return code for this case since we want to
+		# source "defaults" even when an explicit tool path is
+		# configured since the user can use that to override the
+		# default path in the scriptlet.
+		return 2
 	fi
 
 	# Load the redefined functions

@@ -67,11 +71,11 @@ setup_tool () {
 	if merge_mode && ! can_merge
 	then
 		echo "error: '$tool' can not be used to resolve merges" >&2
-		exit 1
+		return 1
 	elif diff_mode && ! can_diff
 	then
 		echo "error: '$tool' can only be used to resolve merges" >&2
-		exit 1
+		return 1
 	fi
 	return 0
 }

@@ -101,6 +105,19 @@ run_merge_tool () {
 
 	# Bring tool-specific functions into scope
 	setup_tool "$1"
+	exitcode=$?
+	case $exitcode in
+	0)
+		:
+		;;
+	2)
+		# The configured tool is not a built-in tool.
+		test -n "$merge_tool_path" || return 1
+		;;
+	*)
+		return $exitcode
+		;;
+	esac
 
 	if merge_mode
 	then

-- 
1.8.1