Wincent Colaiuta <win@xxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html