git/git-difftool--helper.sh, branch v2.50.1

git-difftool--helper.sh: exit upon initialize_merge_tool errors

2024-11-25T02:59:19Z

Since the introduction of 'initialize_merge_tool' in de8dafbada (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 Signed-off-by: Junio C Hamano

git-difftool--helper: honor `--trust-exit-code` with `--dir-diff`

2024-02-20T17:30:32Z

The `--trust-exit-code` option for git-diff-tool(1) was introduced via 2b52123fcf (difftool: add support for --trust-exit-code, 2014-10-26). When set, it makes us return the exit code of the invoked diff tool when diffing multiple files. This patch didn't change the code path where `--dir-diff` was passed because we already returned the exit code of the diff tool unconditionally in that case. This was changed a month later via c41d3fedd8 (difftool--helper: add explicit exit statement, 2014-11-20), where an explicit `exit 0` was added to the end of git-difftool--helper.sh. While the stated intent of that commit was merely a cleanup, it had the consequence that we now to ignore the exit code of the diff tool when `--dir-diff` was set. This change in behaviour is thus very likely an unintended side effect of this patch. Now there are two ways to fix this: - We can either restore the original behaviour, which unconditionally returned the exit code of the diffing tool when `--dir-diff` is passed. - Or we can make the `--dir-diff` case respect the `--trust-exit-code` flag. The fact that we have been ignoring exit codes for 7 years by now makes me rather lean towards the latter option. Furthermore, respecting the flag in one case but not the other would needlessly make the user interface more complex. Fix the bug so that we also honor `--trust-exit-code` for dir diffs and adjust the documentation accordingly. Reported-by: Jean-Rémy Falleri Signed-off-by: Patrick Steinhardt Signed-off-by: Junio C Hamano

mergetool: new config guiDefault supports auto-toggling gui by DISPLAY

2023-04-06T04:03:29Z

When no merge.tool or diff.tool is configured or manually selected, the selection of a default tool is sensitive to the DISPLAY variable; in a GUI session a gui-specific tool will be proposed if found, and otherwise a terminal-based one. This "GUI-optimizing" behavior is important because a GUI can make a huge difference to a user's ability to understand and correctly complete a non-trivial conflicting merge. Some time ago the merge.guitool and diff.guitool config options were introduced to enable users to configure both a GUI tool, and a non-GUI tool (with fallback if no GUI tool configured), in the same environment. Unfortunately, the --gui argument introduced to support the selection of the guitool is still explicit. When using configured tools, there is no equivalent of the no-tool-configured "propose a GUI tool if we are in a GUI environment" behavior. As proposed in , introduce new configuration options, difftool.guiDefault and mergetool.guiDefault, supporting a special value "auto" which causes the corresponding tool or guitool to be selected depending on the presence of a non-empty DISPLAY value. Also support "true" to say "default to the guitool (unless --no-gui is passed on the commandline)", and "false" as the previous default behavior when these new configuration options are not specified. Signed-off-by: Tao Klerks Acked-by: David Aguilar Signed-off-by: Junio C Hamano

mergetool: break setup_tool out into separate initialization function

2021-02-09T22:09:16Z

This is preparation for the following commit where we need to source the mergetool shell script to look for overrides before `run_merge_tool` is called. Previously `run_merge_tool` both sourced that script and invoked the mergetool. In the case of the following commit, we need the result of the `hide_resolved` override, if present, before we actually run `run_merge_tool`. The new `initialize_merge_tool` wrapper is exposed and documented as a public interface for consistency with the existing `run_merge_tool` which is also public. Although `setup_tool` could instead be exposed directly, the related `setup_user_tool` would probably also want to be elevated to match and this felt the cleanest to me. Signed-off-by: Seth House Signed-off-by: Junio C Hamano

mergetool: use get_merge_tool function

2019-05-13T14:11:59Z

In git-mergetool, the logic for getting which merge tool to use is duplicated in git-mergetool--lib, except for the fact that it needs to know whether the tool was guessed or not. Rewrite `get_merge_tool` to return whether or not the tool was guessed through the return code and make git-mergetool call this function instead of duplicating the logic. Note that 1 was chosen to be the return code of when a tool is guessed because it seems like a slightly more abnormal condition than getting a tool that's explicitly specified but this is completely arbitrary. Also, let `$GIT_MERGETOOL_GUI` be set to determine whether or not the guitool will be selected. This change is not completely backwards compatible as there may be external users of git-mergetool--lib. However, only one user, git-diffall[1], was found from searching GitHub and Google, and this tool is superseded by `git difftool --dir-diff` anyway. It seems very unlikely that there exists an external caller that would take into account the return code of `get_merge_tool` as it would always return 0 before this change so this change probably does not affect any external users. [1]: https://github.com/thenigan/git-diffall Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

difftool: always honor fatal error exit codes

2016-08-15T22:24:05Z

At the moment difftool's "trust exit code" logic always suppresses the exit status of the diff utility we invoke. This is useful because we don't want to exit just because diff returned "1" because the files differ, but it's confusing if the shell returns an error because the selected diff utility is not found. POSIX specifies 127 as the exit status for "command not found", 126 for "command found but is not executable" and values greater than 128 if the command terminated because it received a signal [1] and at least bash and dash follow this specification, while diff utilities generally use "1" for the exit status we want to ignore. Handle any value of 126 or greater as a special value indicating that some form of fatal error occurred. [1] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_08_02 Signed-off-by: John Keeping Signed-off-by: Junio C Hamano

difftool/mergetool: make the form of yes/no questions consistent

2016-04-25T22:15:17Z

Every yes/no question in difftool/mergetool scripts has slightly different form, and none of them is consistent with the form git itself uses. Make the form of all the questions consistent with the form used by git. Reviewed-by: John Keeping Signed-off-by: Nikola Forró Acked-by: David Aguilar Signed-off-by: Junio C Hamano

difftool--helper: add explicit exit statement

2014-11-21T19:27:53Z

git-difftool--helper returns a zero exit status unless --trust-exit-code is in effect. Add an explicit exit statement to make this clearer. Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

difftool: add support for --trust-exit-code

2014-10-28T17:36:57Z

Teach difftool to exit when a diff tool returns a non-zero exit code when either --trust-exit-code is specified or difftool.trustExitCode is true. Forward exit codes from invoked diff tools to the caller when --trust-exit-code is used. Suggested-by: Adri Farr <14farresa@gmail.com> Helped-by: Johannes Sixt Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

difftool--helper: exit when reading a prompt answer fails

2014-10-27T18:17:56Z

An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does not quit it, but is treated as if 'yes' was answered to the prompt and all following prompts, which is contrary to the user's intent. Fix the error check. Signed-off-by: Johannes Sixt Signed-off-by: Junio C Hamano