Jeff King [off-list ref] writes:
I'm not sure what you mean here. Are you saying that it is the desired
behavior for "git-diff --color" to use my color.diff.* variables, but
for "git-diff-files --color" not to?
What I meant is "git diff" without --color can be colorized
because of config but we should never allow "git diff-files"
without --color to be colorized by user's config. I realize
that you were talking about the choice of colors, which is a
different issue.
I do not much care ;-), but I guess we would want to be
consistent.
Not to mention the other bug (that diff-files _does_ read the config,
just halfway through).
That one _is_ a bug. diff-files should not be affected by
"diff.color = auto" or somesuch in the config, even when the
user uses custom function header crap.
On Fri, Jan 04, 2008 at 12:35:42AM -0800, Junio C Hamano wrote:
What I meant is "git diff" without --color can be colorized
because of config but we should never allow "git diff-files"
without --color to be colorized by user's config. I realize
that you were talking about the choice of colors, which is a
different issue.
I do not much care ;-), but I guess we would want to be
consistent.
OK, yes, I knew that about diff.color already. But I think it is a bug
to not use the user's colors in "git add -i", and I think the right fix
is to make diff-files consistent in its color choices. Patch will
follow.
That one _is_ a bug. diff-files should not be affected by
"diff.color = auto" or somesuch in the config, even when the
user uses custom function header crap.
It doesn't use it, actually, but I think that is a happy accident of the
way most config options are used (i.e., we _do_ read and change the
config, but we just never look at it again because we have done our
diff_setup). If you could provoke any of the diff plumbing to call
diff_setup twice, you would be in trouble (but even diff-tree --stdin
doesn't do that).
-Peff