Am 17.12.20 um 06:41 schrieb Felipe Contreras: > Seth House wrote: >> I appreciate Felipe getting the discussion started. >> >> On Wed, Dec 16, 2020 at 02:24:23PM -0800, Junio C Hamano wrote: >>> If there is none, then what is the benefit of doing the same thing >>> without running 3 checkout-index? >> >> I wasn't aware of this plubming when I wrote the initial shell-script >> version of the technique. This is a much better approach (even *if* >> there's a negligible performance penalty). This nicely avoids >> UNIX/Windows line-ending surprises, and instead leans on >> already-configured Git defaults for those. Plus the non-text files >> benefit you mentioned is also huge. > > I think you misunderstood. > > This command: > > git checkout-index --stage 2 --temp -- poem.txt > > Will give you *exactly* the same output as LOCAL. > > The context is "git mergetool", not the mergetool itself. > >>> as I understand "mergetool" is handed an >>> already conflicted state and asked to resolve it, it would not be >>> possible without at least looking at the stage #1 to recover the >>> base for folks who do not use diff3 style. >> >> I feel strongly that LOCAL, REMOTE, and BASE should be left intact for >> this reason, Also because they aid readers in understanding the >> pre-conflicts versions of the file. >> >> Rather mergetools (that support it) should be given the stage 1-3 >> versions of the file in addition to the usual, unmodified, above three. >> Then each tool can decide whether or how to show each. Some graphical >> tools might be able to make effective use of all five (six?). > > Except as you stated in your blog post, not a *single* tool does this > correctly using LOCAL, REMOTE, and BASE. > > * Araxis: a mess of changes > * Beyond Compare: a mess of changes > * DiffMerge: a mess of changes > * kdiff3: a mess of changes > * Meld: a mess of changes > * Sublime Merge: displays unnecessary changes > * SmartGit: ignores the other files > * Fork: displays unnecessary changes > * P4Merge: displays unnecessary changes > * IntelliJ: a mess of changes > * Tortoise Merge: uncertain > * tkdiff: displays unnecessary changes > * vimdiff: so, so wrong > * vimdiff2: displays unnecessary changes > * diffconflicts: RIGHT! > > So all tools would benefit from the patch (except yours). > > Which tool would be negatively affected? Where's WinMerge in your list? I'm mostly using WinMerge these days, and it can do what your patch does all by itself. It does not require the proposed post-processing of stages in order to show only the real conflicts. I would say that this is a hint that post-processing should be moved to the tool drivers, and should not be done at the proposed level. I don't know, though, whether your patch would have a negative effect for WinMerge. -- Hannes
