[PATCH 2 of 2 V2] extdiff: add --mode option

Ludovic Chabant ludovic at chabant.com
Sun Jan 13 18:31:07 EST 2019


> A separate patch seems fine. To make clear, there's no need to check if the
> tool is console-based or not unless multiple diff processes are spawned
> simultaneously. Currently the .gui flag is tested only by filemerge.py.

So you mean I don't need to modify the previous code path (dir-diff), nor do I need to check the gui flag if the "confirm" flag is given (i.e. one external process at a time)?
How come? Wouldn't even one gui process be a problem if you're in a shell-only instance of hg?


> The latter looks worse for me. Instead, you can use [alias] to pass in
> arguments to hg commands.

That's true, but then the entire extdiff configuration section would be deprecated if that was the case, no?
Like, AFAIK there's not much difference between:

[extdiff]
cmd.bcomp = /path/to/bcomp
opts.bcomp = --whatever

and:

[alias]
bcomp = extdiff -p /path/to/bcomp -o "--whatever"

I assume the point of extdiff is to be a slighly better version of an alias for the purpose of a diffing stuff, but maybe someone with a better knowledge of the history of both features can correct me.

More importantly, I actually just realized (maybe) why a --mode option might be better. Remember how I intended to have, say, BeyondCompare setup to do per-file-diffs by default, and I would pass a dir-diff option for the 5% cases where I want to only diff a few files in a revision?
Well, if we have multiple flags, the extdiff/alias/whatever section of my .hgrc would specify --per-file (so I get per-file diffs by default), but if I then pass --dir (to revert back to a dir-diff), it wouldn't override the default... the extdiff command would instead get both --per-file and --dir, and would most likely throw an error because it doesn't make sense to pass those options togethers.
However, with a --mode option, the one I pass on the command line would correctly override the one specified in the .hgrc, and everything works as you would expect... does that make sense?
-- 
 l u d o .
 . 8 0 17 80


More information about the Mercurial-devel mailing list