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

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

mergetool: avoid letting `list_tool_variants` break user-defined setups

2020-11-11T21:00:11Z

In 83bbf9b92ea8 (mergetool--lib: improve support for vimdiff-style tool variants, 2020-07-29), we introduced a `list_tool_variants` function in the spirit of Postel's Law: be lenient in what you accept as input. In this particular instance, we wanted to allow not only `bc` but also `bc3` as name for the Beyond Compare tool. However, what this patch overlooked is that it is totally allowed for users to override the defaults in `mergetools/`. But now that we strip off trailing digits, the name that the user gave the tool might not actually be in the list produced by `list_tool_variants`. So let's do the same as for the `diff_cmd` and the `merge_cmd`: override it with the trivial version in case a user-defined setup was detected. Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

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