Re: What's cooking in git.git (Mar 2009, #06; Sat, 21)

[Junio C Hamano <gitster@pobox.com>]

Wincent Colaiuta <win@wincent.com> writes:

>> Given that git-difftool shares basically all the same options as
>> "git diff", I think a good long-term plan would be looking at adding
>> the "--tool" option to "git diff" itself so that users wouldn't have
>> to learn a new subcommand, just a new option.
>
> What do people think?

I am not "people" but since I was "To:"ed not "Cc:"ed...

I did not comment on it because personally I was not very interested in
it; admittedly, I do not use difftool myself, but:

 (1) "git diff --tool" is more to type than "git difftool"; and

 (2) it requires adding more code to "git diff" for a dubious benefit from
     end user's point of view.

"git diff" itself is already just a thin command dispatcher that calls
underlying vastly different modes operations, and it is designed that way
in order to make it easy to add a new totally different mode of operation.

We originally had four underlying modes of operation (index-with-worktree,
tree-with-tree, tree-with-worktree, and tree-with-index), and Dscho
managed to add random-file-with-random-file without disturbing existing
codepaths too much.

Even though it is a "thin" dispatcher, command line parsing is largely
done by "git diff" itself, and its results are fed to the underlying modes
of operations, for two reasons:

 (1) These "modes of operations" share large set of options (e.g. "-U20"
     works the same way no matter which mode you invoke); and

 (2) the dispatcher needs to inspect command line option and arguments to
     decide which mode to invoke anyway.

When an end user says "I want to compare two things with these settings
(e.g. use color, with 5 lines of context, only inside Documentation/howto
directory, detect renames with lower-than-usual threashold, ...)", the
mental model is same whether the two things being compared happens to be
index-vs-worktree or tree-vs-index from the end user's point of view.  It
makes a lot of sense for "git diff --options" to invoke both modes of
operations with a similar-looking command line.

Even though the --no-index mode of operation internally does not fit very
well compared to the original four modes from the implementation point of
view, it still naturally fits the end user's mental model and that is why
it is given as an option to "git diff".

Does "git difftool" fit well in the end user's mental model in a similar
way to "git diff"?  I somehow suspect it doesn't.  What does it mean to
give "-U8 --color --stat --summary -p --ignore-space-at-eol" options when
you invoke it, for example?