[BUG] git-diff-* --color oddness

[Jeff King <peff@peff.net>]

I encountered some weirdness today with git-diff-{files,tree,index} and
--color.  They parse the --color command line option, but do _not_ call
git_config(git_diff_ui_config), so if the user has colors specified in
the config, they are not used.

Ordinarily, I would say "nobody should use --color with diff-files". But
we do, in git-add--interactive (see Wincent's 4af756f3). So we can
probably fix that with a "git_diff_minimal_ui_config" which does just
the colors, and use that from the plumbing diff scripts (or just move
the color stuff into git_default_config).

But it gets worse. Try this:

  # make a custom color
  git config color.diff.meta yellow
  # now show a plumbing diff
  git diff-tree --color -p 257f3020^ 257f3020

The first two lines of meta-info will be in the stock colors, but
everything after will be in the custom colors. So we are actually
reading the diff_ui options _during_ the diff. The culprit is
funcname_pattern, which calls read_config_if_needed.

It's my understanding that diff_ui_config is about porcelain diff
options, so it is a bit worrisome that in the middle of a plumbing diff
process, we load porcelain config. Fortunately, most of them aren't
looked at except in diff_setup, which has already run. Colors actually
affect globals which are used during the diff, and so are noticed.

So I think the best course is probably:
  1. before v1.5.4, we need to fix the color handling in "git-diff -i",
     either by declaring git-diff-files --color illegal and finding
     another way to do 4af756f3, or by moving the diff color
     functionality into the default config.

  2. Probably post-v1.5.4, some thought should be given to
     how the diff ui config is demand-loaded by
     diff.c:read_config_if_needed. I don't _think_ it is a problem for
     now except for the colors, because most parts just get used in
     diff_setup. But it seems a bit flaky.

-Peff