[PATCH V3] extdiff: add --per-file and --confirm options

Ludovic Chabant ludovic at chabant.com
Wed Jan 30 11:57:07 EST 2019


> My point was that it could be addressed by checking the gui flag (or adding
> new dedicated flag to [diff/merge-tools].) It's a tool property whether
> multiple processes can be spawned or not.

After testing a bit, it turns out it's actually a bit more complicated than I anticipated. Consider this:

[extdiff]
blah =

[diff-tools]
blah.gui = True

[merge-tools]
blah.diffargs = -a -b -c

The extdiff command will find the options to use on the command line from the [merge-tools] sections. Does this mean we ignore the "gui = True" from [diff-tools] even though that's clearly intended for *diff commands to use?
It could also be the opposite, where the "diffargs" are found in [diff-tools] and "gui" is set in [merge-tools].

And there's the case where no "diffargs" are provided anywhere, in which case the "gui" setting might be taken from wherever we find, leading to the problem where, if you have:

[extdiff]
blah =

[merge-tools]
blah.gui = True

...then it will consider "blah" to be a GUI tool... until you add a [diff-tools] section with "blah.diffargs" and suddenly "blah" isn't considered a GUI anymore because the presence of a "diffargs" setting there made us stop looking at the [merge-tools] section.

I think the best we can do might be to look for "gui" in [merge-tools] _only_ if "diffargs" is also there, and otherwise _only_ look for "gui" in [diff-tools]...  ideas?

Unless I'm missing something, I feels like we're basically reaching the limits of the, ahem, rather organic spec of the extdiff command (there's not even a help topic on "config.diff-tools"). After we solve this, I would be totally ok working on some patches to make a core "hg difftool" command or something, with a more strict UX.

-- 
 l u d o .
 . 8 0 17 80


More information about the Mercurial-devel mailing list