Johannes Sixt wrote: > Am 17.12.20 um 06:45 schrieb Felipe Contreras: > > It doesn't make sense to display easily-solvable conflicts in the > > different views of all mergetools. > > > > Only the chunks that warrant conflict markers should be displayed. > > > > In order to unobtrusively do this, add a new configuration: > > mergetool.autoMerge. > > > > See Seth House's blog post [1] for the idea, and the rationale. > > > > [1] https://www.eseth.org/2020/mergetools.html > > > > Original-idea-by: Seth House <seth@xxxxxxxxx> > > Signed-off-by: Felipe Contreras <felipe.contreras@xxxxxxxxx> > > --- > > Documentation/config/mergetool.txt | 3 +++ > > git-mergetool.sh | 10 ++++++++++ > > t/t7610-mergetool.sh | 18 ++++++++++++++++++ > > 3 files changed, 31 insertions(+) > > > > diff --git a/Documentation/config/mergetool.txt b/Documentation/config/mergetool.txt > > index 16a27443a3..43af7a96f9 100644 > > --- a/Documentation/config/mergetool.txt > > +++ b/Documentation/config/mergetool.txt > > @@ -61,3 +61,6 @@ mergetool.writeToTemp:: > > > > mergetool.prompt:: > > Prompt before each invocation of the merge resolution program. > > + > > +mergetool.autoMerge:: > > + Automatically resolve conflicts that don't require user intervention. > > As I hinted in an earlier message, some tools do know how to deal with > unconflicted changes. This should be a setting in the tool driver, not a > user-visible setting. It could be done in both. We first should find a mergetool that is negatively affected by this, which WinMerge doesn't seem to be one of them: 1. Before: https://snipboard.io/8JA5Oz.jpg 2. After: https://snipboard.io/HUXnOg.jpg That's a positive effect after the patch. -- Felipe Contreras
