git/git-mergetool--lib.sh, branch v2.29.2

mergetools: add support for nvimdiff (neovim) family

2020-07-29T21:44:49Z

Signed-off-by: pudinha Signed-off-by: Junio C Hamano

mergetool--lib: improve support for vimdiff-style tool variants

2020-07-29T21:44:46Z

The merge tools vimdiff2, vimdiff3, gvimdiff2, gvimdiff3 and bc3 are all variants of the main tools vimdiff and bc. They are implemented in the main and a one-liner script that just sources it exist for each. Allow variants ending in [0-9] to be correctly wired without the need for such one-liners, so instead of 5 scripts, only 1 (gvimdiff) is needed. Signed-off-by: pudinha Signed-off-by: Junio C Hamano

Merge branch 'dl/difftool-mergetool'

2019-05-19T07:45:30Z

Update "git difftool" and "git mergetool" so that the combinations of {diff,merge}.{tool,guitool} configuration variables serve as fallback settings of each other in a sensible order. * dl/difftool-mergetool: difftool: fallback on merge.guitool difftool: make --gui, --tool and --extcmd mutually exclusive mergetool: fallback to tool when guitool unavailable mergetool--lib: create gui_mode function mergetool: use get_merge_tool function t7610: add mergetool --gui tests t7610: unsuppress output

mergetool: fallback to tool when guitool unavailable

2019-05-13T14:11:59Z

In git-difftool, if the tool is called with --gui but `diff.guitool` is not set, it falls back to `diff.tool`. Make git-mergetool also fallback from `merge.guitool` to `merge.tool` if the former is undefined. If git-difftool, when called with `--gui`, were to use `get_configured_mergetool` in a future patch, it would also get the fallback behavior in the following precedence: 1. diff.guitool 2. merge.guitool 3. diff.tool 4. merge.tool The behavior for when difftool or mergetool are called without `--gui` should be identical with or without this patch. Note that the search loop could be written as sections="merge" keys="tool" if diff_mode then sections="diff $sections" fi if gui_mode then keys="guitool $keys" fi merge_tool=$( IFS=' ' for key in $keys do for section in $sections do selected=$(git config $section.$key) if test -n "$selected" then echo "$selected" return fi done done) which would make adding a mode in the future much easier. However, adding a new mode will likely never happen as it is highly discouraged so, as a result, it is written in its current form so that it is more readable for future readers. Signed-off-by: Denton Liu Signed-off-by: Junio C Hamano

mergetool--lib: create gui_mode function

2019-05-13T14:11:59Z

Before, in `get_configured_merge_tool`, we would test the value of the first argument directly, which corresponded to whether we were using guitool. However, since `$GIT_MERGETOOL_GUI` is available as an environment variable, create the `gui_mode` function which increases the clarify of functions which use it. While we're at it, add a space before `()` in function definitions to fix the style. Signed-off-by: Denton Liu 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

mergetools: add support for smerge (Sublime Merge)

2019-04-04T09:21:25Z

Teach difftool and mergetool about the Sublime Merge "smerge" command. Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

mergetool: accept -g/--[no-]gui as arguments

2018-10-25T05:01:10Z

In line with how difftool accepts a -g/--[no-]gui option, make mergetool accept the same option in order to use the `merge.guitool` variable to find the default mergetool instead of `merge.tool`. Signed-off-by: Denton Liu Signed-off-by: Anmol Mago Signed-off-by: Brian Ho Signed-off-by: David Lu Signed-off-by: Ryan Wang Acked-by: David Aguilar Signed-off-by: Junio C Hamano

mergetool: honor mergetool.$tool.trustExitCode for built-in tools

2016-11-29T18:54:03Z

Built-in merge tools contain a hard-coded assumption about whether or not a tool's exit code can be trusted to determine the success or failure of a merge. Tools whose exit codes are not trusted contain calls to check_unchanged() in their merge_cmd() functions. A problem with this is that the trustExitCode configuration is not honored for built-in tools. Teach built-in tools to honor the trustExitCode configuration. Extend run_merge_cmd() so that it is responsible for calling check_unchanged() when a tool's exit code cannot be trusted. Remove check_unchanged() calls from scriptlets since they are no longer responsible for calling it. When no configuration is present, exit_code_trustable() is checked to see whether the exit code should be trusted. The default implementation returns false. Tools whose exit codes can be trusted override exit_code_trustable() to true. Reported-by: Dun Peal Signed-off-by: David Aguilar Signed-off-by: Junio C Hamano

Merge branch 'nf/mergetool-prompt'

2016-05-03T21:08:17Z

UI consistency improvements. * nf/mergetool-prompt: difftool/mergetool: make the form of yes/no questions consistent