git-mergetool: improve error code paths and messages #1827
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Philippe Blain <[email protected]>
In git-mergetool--lib.sh::get_merge_tool_path, we check if the chosen tool is valid via valid_tool and exit with an error message if not. This error message mentions "Unknown merge tool", even if the command the user tried was 'git difftool --tool=unknown'. Use the global 'TOOL_MODE' variable for a more correct error message. Signed-off-by: Philippe Blain <[email protected]>
In git-mergetool--lib.sh::setup_tool, we check if the given tool is a
known builtin tool, a known variant, or a user-defined tool by calling
setup_user_tool, and we return with the exit code from setup_user_tool
if it was called. setup_user_tool checks if {diff,merge}tool.$tool.cmd
is set and quietly returns with an error if not.
This leads to the following invocation quietly failing:
git mergetool --tool=unknown
which is not very user-friendly. Adjust setup_user_tool to output an
error message before returning if {diff,merge}tool.$tool.cmd is not set.
Adjust the second call to setup_user_tool in setup_tool to silence this
new error, as this call is only meant to allow users to redefine 'cmd'
for a builtin tool; it is not an error if they have not done so (which
is why we do not check the return status of this call).
Note that this behaviour of quietly failing is a regression dating back
to de8dafb (mergetool: break setup_tool out into separate
initialization function, 2021-02-09), as before this commit an unknown
mergetool would be diagnosed in get_merge_tool_path when called from
run_merge_tool.
Signed-off-by: Philippe Blain <[email protected]>
In setup_tool, we check if the given tool is a known variant of a tool, and quietly return with an error if not. This leads to the following invocation quietly failing: git mergetool --tool=vimdiff4 Add an error message before returning in this case. Signed-off-by: Philippe Blain <[email protected]>
Since the introduction of 'initialize_merge_tool' in de8dafb (mergetool: break setup_tool out into separate initialization function, 2021-02-09), any errors from this function are ignored in git-difftool--helper.sh::launch_merge_tool, which is not the case for its call in git-mergetool.sh::merge_file. Despite the in-code comment, initialize_merge_tool (via its call to setup_tool) does different checks than run_merge_tool, so it makes sense to abort early if it encounters errors. Add exit calls if initialize_merge_tool fails. Signed-off-by: Philippe Blain <[email protected]>
|
/submit |
2 similar comments
|
/submit |
|
/submit |
|
Submitted as [email protected] To fetch this version into To fetch this version to local tag |
|
Hi @dscho ! My first two tries (one, two) at |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -474,7 +474,7 @@ get_merge_tool_path () { | |||
| merge_tool="$1" | |||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Philippe Blain via GitGitGadget" <[email protected]> writes:
> From: Philippe Blain <[email protected]>
>
> In git-mergetool--lib.sh::get_merge_tool_path, we check if the chosen
> tool is valid via valid_tool and exit with an error message if not. This
> error message mentions "Unknown merge tool", even if the command the
> user tried was 'git difftool --tool=unknown'. Use the global 'TOOL_MODE'
> variable for a more correct error message.
Makes sense. Is this something we can easily test to catch future
regression, or is it too trivial to matter?
I wouldn't mind if the answer were "the latter" ;-)
Thanks.
> Signed-off-by: Philippe Blain <[email protected]>
> ---
> git-mergetool--lib.sh | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 1ff26170ffc..269a60ea44c 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -474,7 +474,7 @@ get_merge_tool_path () {
> merge_tool="$1"
> if ! valid_tool "$merge_tool"
> then
> - echo >&2 "Unknown merge tool $merge_tool"
> + echo >&2 "Unknown $TOOL_MODE tool $merge_tool"
> exit 1
> fi
> if diff_mode
| @@ -159,14 +159,18 @@ check_unchanged () { | |||
| } | |||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Philippe Blain via GitGitGadget" <[email protected]> writes:
> valid_tool () {
> - setup_tool "$1" && return 0
> + setup_tool "$1" 2>/dev/null && return 0
> cmd=$(get_merge_tool_cmd "$1")
> test -n "$cmd"
> }
As we are checking if a tool is valid, it is normal for setup_tool
to fail when we are checking is not valid (aka "fails to get set
up"). There is no need to show an error message for such a failure,
as the callers of valid_tool would do so if they wish. OK.
> setup_user_tool () {
> merge_tool_cmd=$(get_merge_tool_cmd "$tool")
> - test -n "$merge_tool_cmd" || return 1
> + if test -z "$merge_tool_cmd"
> + then
> + echo >&2 "error: ${TOOL_MODE}tool.$tool.cmd not set for tool '$tool'"
> + return 1
> + fi
There are only two callers of setup_user_tool, and one of them
squelches this message by sending it to /dev/null. The error
message composed here does not use anything that is unique to the
function (in other words, $tool and ${TOOL_MODE} are available to
its callers).
I wonder if it is a better design to leave this one as-is, and
instead show the error message from the other caller of
setup_user_tool that does not squelch the message? Are we planning
to add more callers of this function that want to show the same
message?
> diff_cmd () {
> ( eval $merge_tool_cmd )
> @@ -255,7 +259,7 @@ setup_tool () {
>
> # Now let the user override the default command for the tool. If
> # they have not done so then this will return 1 which we ignore.
> - setup_user_tool
> + setup_user_tool 2>/dev/null
If we did that, then this change can be dropped. Instead, a few
lines above this hunk, we can give the error message ourselves from
this setup_tool function.
> if ! list_tool_variants | grep -q "^$tool$"
> then
> diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
> index 22b3a85b3e9..82a88107850 100755
> --- a/t/t7610-mergetool.sh
> +++ b/t/t7610-mergetool.sh
> @@ -898,4 +898,12 @@ test_expect_success 'mergetool with guiDefault' '
> git commit -m "branch1 resolved with mergetool"
> '
>
> +test_expect_success 'mergetool with non-existent tool' '
> + test_when_finished "git reset --hard" &&
> + git checkout -b test$test_count branch1 &&
> + test_must_fail git merge main &&
> + yes "" | test_must_fail git mergetool --tool=absent >out 2>&1 &&
> + test_grep -i "not set for tool" out
> +'
Why "-i"? I do not offhand see the reason why we want to be loose
here.
The "${TOOL_MODE}tool" part may also want to be verified, perhaps,
which was related to the topic of the fix in [2/5]?
| @@ -255,10 +259,11 @@ setup_tool () { | |||
|
|
|||
| # Now let the user override the default command for the tool. If | |||
| # they have not done so then this will return 1 which we ignore. | |||
| setup_user_tool | |||
| setup_user_tool 2>/dev/null | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Philippe Blain via GitGitGadget" <[email protected]> writes:
> From: Philippe Blain <[email protected]>
>
> In setup_tool, we check if the given tool is a known variant of a tool,
> and quietly return with an error if not. This leads to the following
> invocation quietly failing:
>
> git mergetool --tool=vimdiff4
>
> Add an error message before returning in this case.
Makes sense, but ...
> Signed-off-by: Philippe Blain <[email protected]>
> ---
> git-mergetool--lib.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index f4786afc63f..9a00fabba27 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -263,6 +263,7 @@ setup_tool () {
>
> if ! list_tool_variants | grep -q "^$tool$"
> then
> + echo "error: unknown ${tool%[0-9]} variant '$tool'" >&2
... I do not understand why you strip a single digit from the end.
git mergetool --tool=nvimdiff4
says 'nvimdiff4' is not known as a variant of 'nvimdiff', but
wouldn't it still be a variant of 'vimdiff'? Of course,
git mergetool --tool=nvimdiff48
gets a vastly different error message ;-)
Saying
echo >&2 "error: unknown variant '$tool'"
may be sufficient, perhaps? I dunno.
> return 1
> fi
|
This patch series was integrated into seen via git@a35aba8. |
@phil-blain sorry for the woes! Your analysis is indeed correct. I now changed the Pipeline definition to use v1 of that task (instead of v0), and I checked off the "Check for Latest Version" checkbox. That should be good enough. |
|
This patch series was integrated into seen via git@37181c6. |
|
This patch series was integrated into seen via git@5006b1c. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
These are a few improvements to improve existing error messages in 'git mergetool', and make sure that errors are not quiet, along with a small completion update in 1/1.
CC: Seth House [email protected]
CC: David Aguilar [email protected]
CC: Johannes Sixt [email protected]