2018-10-27 08:23:20 +02:00
|
|
|
mergetool.<tool>.path::
|
|
|
|
|
Override the path for the given tool. This is useful in case
|
|
|
|
|
your tool is not in the PATH.
|
|
|
|
|
|
|
|
|
|
mergetool.<tool>.cmd::
|
|
|
|
|
Specify the command to invoke the specified merge tool. The
|
|
|
|
|
specified command is evaluated in shell with the following
|
|
|
|
|
variables available: 'BASE' is the name of a temporary file
|
|
|
|
|
containing the common base of the files to be merged, if available;
|
|
|
|
|
'LOCAL' is the name of a temporary file containing the contents of
|
|
|
|
|
the file on the current branch; 'REMOTE' is the name of a temporary
|
|
|
|
|
file containing the contents of the file from the branch being
|
|
|
|
|
merged; 'MERGED' contains the name of the file to which the merge
|
|
|
|
|
tool should write the results of a successful merge.
|
|
|
|
|
|
2021-02-09 21:07:12 +01:00
|
|
|
mergetool.<tool>.hideResolved::
|
|
|
|
|
Allows the user to override the global `mergetool.hideResolved` value
|
|
|
|
|
for a specific tool. See `mergetool.hideResolved` for the full
|
|
|
|
|
description.
|
|
|
|
|
|
2018-10-27 08:23:20 +02:00
|
|
|
mergetool.<tool>.trustExitCode::
|
|
|
|
|
For a custom merge command, specify whether the exit code of
|
|
|
|
|
the merge command can be used to determine whether the merge was
|
|
|
|
|
successful. If this is not set to true then the merge target file
|
|
|
|
|
timestamp is checked and the merge assumed to have been successful
|
|
|
|
|
if the file has been updated, otherwise the user is prompted to
|
|
|
|
|
indicate the success of the merge.
|
|
|
|
|
|
|
|
|
|
mergetool.meld.hasOutput::
|
|
|
|
|
Older versions of `meld` do not support the `--output` option.
|
|
|
|
|
Git will attempt to detect whether `meld` supports `--output`
|
|
|
|
|
by inspecting the output of `meld --help`. Configuring
|
|
|
|
|
`mergetool.meld.hasOutput` will make Git skip these checks and
|
|
|
|
|
use the configured value instead. Setting `mergetool.meld.hasOutput`
|
|
|
|
|
to `true` tells Git to unconditionally use the `--output` option,
|
|
|
|
|
and `false` avoids using `--output`.
|
|
|
|
|
|
2020-05-07 01:31:14 +02:00
|
|
|
mergetool.meld.useAutoMerge::
|
|
|
|
|
When the `--auto-merge` is given, meld will merge all non-conflicting
|
|
|
|
|
parts automatically, highlight the conflicting parts and wait for
|
|
|
|
|
user decision. Setting `mergetool.meld.useAutoMerge` to `true` tells
|
|
|
|
|
Git to unconditionally use the `--auto-merge` option with `meld`.
|
|
|
|
|
Setting this value to `auto` makes git detect whether `--auto-merge`
|
|
|
|
|
is supported and will only use `--auto-merge` when available. A
|
|
|
|
|
value of `false` avoids using `--auto-merge` altogether, and is the
|
|
|
|
|
default value.
|
|
|
|
|
|
2021-02-09 21:07:10 +01:00
|
|
|
mergetool.hideResolved::
|
|
|
|
|
During a merge Git will automatically resolve as many conflicts as
|
|
|
|
|
possible and write the 'MERGED' file containing conflict markers around
|
|
|
|
|
any conflicts that it cannot resolve; 'LOCAL' and 'REMOTE' normally
|
|
|
|
|
represent the versions of the file from before Git's conflict
|
|
|
|
|
resolution. This flag causes 'LOCAL' and 'REMOTE' to be overwriten so
|
|
|
|
|
that only the unresolved conflicts are presented to the merge tool. Can
|
|
|
|
|
be configured per-tool via the `mergetool.<tool>.hideResolved`
|
mergetool: do not enable hideResolved by default
When 98ea309b3f (mergetool: add hideResolved configuration,
2021-02-09) introduced the mergetool.hideResolved setting to reduce
the clutter in viewing non-conflicted sections of files in a
mergetool, it enabled it by default, explaining:
No adverse effects were noted in a small survey of popular mergetools[1]
so this behavior defaults to `true`.
In practice, alas, adverse effects do appear. A few issues:
1. No indication is shown in the UI that the base, local, and remote
versions shown have been modified by additional resolution. This
is inherent in the design: the idea of mergetool.hideResolved is to
convince a mergetool that expects pristine local, base, and remote
files to show partially resolved verisons of those files instead;
there is no additional source of information accessible to the
mergetool to see where the resolution has happened.
(By contrast, a mergetool generating the partial resolution from
conflict markers for itself would be able to hilight the resolved
sections with a different color.)
A user accustomed to seeing the files without partial resolution
gets no indication that this behavior has changed when they upgrade
Git.
2. If the computed merge did not line up the files correctly (for
example due to repeated sections in the file), the partially
resolved files can be misleading and do not have enough information
to reconstruct what happened and compute the correct merge result.
3. Resolving a conflict can involve information beyond the textual
conflict. For example, if the local and remote versions added
overlapping functionality in different ways, seeing the full
unresolved versions of each alongside the base gives information
about each side's intent that makes it possible to come up with a
resolution that combines those two intents. By contrast, when
starting with partially resolved versions of those files, one can
produce a subtly wrong resolution that includes redundant extra
code added by one side that is not needed in the approach taken
on the other.
All that said, a user wanting to focus on textual conflicts with
reduced clutter can still benefit from mergetool.hideResolved=true as
a way to deemphasize sections of the code that resolve cleanly without
requiring any changes to the invoked mergetool. The caveats described
above are reduced when the user has explicitly turned this on, because
then the user is aware of them.
Flip the default to 'false'.
Reported-by: Dana Dahlstrom <dahlstrom@google.com>
Helped-by: Seth House <seth@eseth.com>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-03-13 09:38:48 +01:00
|
|
|
configuration variable. Defaults to `false`.
|
2021-02-09 21:07:10 +01:00
|
|
|
|
2018-10-27 08:23:20 +02:00
|
|
|
mergetool.keepBackup::
|
|
|
|
|
After performing a merge, the original file with conflict markers
|
|
|
|
|
can be saved as a file with a `.orig` extension. If this variable
|
|
|
|
|
is set to `false` then this file is not preserved. Defaults to
|
|
|
|
|
`true` (i.e. keep the backup files).
|
|
|
|
|
|
|
|
|
|
mergetool.keepTemporaries::
|
|
|
|
|
When invoking a custom merge tool, Git uses a set of temporary
|
|
|
|
|
files to pass to the tool. If the tool returns an error and this
|
|
|
|
|
variable is set to `true`, then these temporary files will be
|
|
|
|
|
preserved, otherwise they will be removed after the tool has
|
|
|
|
|
exited. Defaults to `false`.
|
|
|
|
|
|
|
|
|
|
mergetool.writeToTemp::
|
|
|
|
|
Git writes temporary 'BASE', 'LOCAL', and 'REMOTE' versions of
|
|
|
|
|
conflicting files in the worktree by default. Git will attempt
|
|
|
|
|
to use a temporary directory for these files when set `true`.
|
|
|
|
|
Defaults to `false`.
|
|
|
|
|
|
|
|
|
|
mergetool.prompt::
|
|
|
|
|
Prompt before each invocation of the merge resolution program.
|
