git/git-mergetool--lib.sh, branch jch

git-mergetool--lib.sh: add error message for unknown tool variant

2024-11-25T02:59:19Z

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 Signed-off-by: Junio C Hamano

git-mergetool--lib.sh: add error message if 'setup_user_tool' fails

2024-11-25T02:59:19Z

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_tool to output an error message before returning if setup_user_tool returned with an error. Note that we do not check the result of the second call to setup_user_tool in setup_tool, 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. Note that this behaviour of quietly failing is a regression dating back to de8dafbada (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 Signed-off-by: Junio C Hamano

git-mergetool--lib.sh: use TOOL_MODE when erroring about unknown tool

2024-11-25T02:59:19Z

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 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

vimdiff: add tool documentation

2022-04-03T22:09:52Z

Running 'git {merge,diff}tool --tool-help' now also prints usage information about the vimdiff tool (and its variants) instead of just its name. Two new functions ('diff_cmd_help()' and 'merge_cmd_help()') have been added to the set of functions that each merge tool (ie. scripts found inside "mergetools/") can overwrite to provided tool specific information. Right now, only 'mergetools/vimdiff' implements these functions, but other tools are encouraged to do so in the future, specially if they take configuration options not explained anywhere else (as it is the case with the 'vimdiff' tool and the new 'layout' option) Note that the function 'show_tool_names', used in the implementation of 'git mergetool --tool-help', is also used in Documentation/Makefile to generate the list of allowed values for the configuration variables '{diff,merge}.{gui,}tool'. Adjust the rule so its output is an Asciidoc "description list" instead of a plain list, with the tool name as the item and the newly added tool description as the description. In addition, a section has been added to "Documentation/git-mergetool.txt" to explain the new "layout" configuration option with examples. Helped-by: Philippe Blain Signed-off-by: Fernando Ramos Signed-off-by: Junio C Hamano

Merge branch 'sh/mergetool-hideresolved'

2021-02-18T01:21:41Z

"git mergetool" feeds three versions (base, local and remote) of a conflicted path unmodified. The command learned to optionally prepare these files with unconflicted parts already resolved. * sh/mergetool-hideresolved: mergetool: add per-tool support and overrides for the hideResolved flag mergetool: break setup_tool out into separate initialization function mergetool: add hideResolved configuration

mergetool: add per-tool support and overrides for the hideResolved flag

2021-02-09T22:09:16Z

Add a per-tool override flag so that users may enable the flag for one tool and disable it for another by setting `mergetool..hideResolved` to `false`. In addition, the author or maintainer of a mergetool may optionally override the default `hideResolved` value for that mergetool. If the `mergetools/` shell script contains a `hide_resolved_enabled` function it will be called when the mergetool is invoked and the return value will be used as the default for the `hideResolved` flag. hide_resolved_enabled () { return 1 } Disabling may be desirable if the mergetool wants or needs access to the original, unmodified 'LOCAL' and 'REMOTE' versions of the conflicted file. For example: - A tool may use a custom conflict resolution algorithm and prefer to ignore the results of Git's conflict resolution. - A tool may want to visually compare/constrast the version of the file from before the merge (saved to 'LOCAL', 'REMOTE', and 'BASE') with Git's conflict resolution results (saved to 'MERGED'). Helped-by: Johannes Sixt Helped-by: Junio C Hamano Signed-off-by: Seth House 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

Merge branch 'pb/mergetool-tool-help-fix'

2021-01-16T05:48:46Z

Fix 2.29 regression where "git mergetool --tool-help" fails to list all the available tools. * pb/mergetool-tool-help-fix: mergetool--lib: fix '--tool-help' to correctly show available tools

mergetool--lib: fix '--tool-help' to correctly show available tools

2021-01-07T02:31:27Z

Commit 83bbf9b92e (mergetool--lib: improve support for vimdiff-style tool variants, 2020-07-29) introduced a regression in the output of `git mergetool --tool-help` and `git difftool --tool-help` [1]. In function 'show_tool_names' in git-mergetool--lib.sh, we loop over the supported mergetools and their variants and accumulate them in the variable 'variants', separating them with a literal '\n'. The code then uses 'echo $variants' to turn these '\n' into newlines, but this behaviour is not portable, it just happens to work in some shells, like dash(1)'s 'echo' builtin. For shells in which 'echo' does not turn '\n' into newlines, the end result is that the only tools that are shown are the existing variants (except the last variant alphabetically), since the variants are separated by actual newlines in '$variants' because of the several 'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants. Fix this bug by embedding an actual line feed into `variants` in show_tool_names(). While at it, replace `sort | uniq` by `sort -u`. To prevent future regressions, add a simple test that checks that a few known tools are correctly shown (let's avoid counting the total number of tools to lessen the maintenance burden when new tools are added or if '--tool-help' learns additional logic, like hiding tools depending on the current platform). [1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/ Reported-by: Philippe Blain Based-on-patch-by: Johannes Sixt Signed-off-by: Philippe Blain Signed-off-by: Junio C Hamano