Hi Will,
Will Palmer wrote:
> Here we add the %C?colorname placeholders which act just as the
> %Ccolorname placeholders, with the exception that the pretty_context is
> checked to see if color should be used according to configuration
Thanks for tackling this.
I have thought a little about a related problem: some commands have
configuration for the colors they use, like:
color.grep.<slot>
Use customized color for grep colorization. <slot> specifies which
part of the line to use the specified color, and is one of
context
non-matching text in context lines (when using -A, -B, or -C)
filename
filename prefix (when not using -h)
This is nice because in certain situations (e.g. different background
colors), the default colors might not be suitable. As an example of
this, the ‘commit ’ line of ‘git log’ output uses color.diff.commit.
So it would be nice to be able to use %C(diff.commit) and
automatically use the right color, if color is enabled.
Why not make %C always check? I can understand that it would be
annoying when first trying to use %C. On the other hand, it would be
more convenient for writing format.pretty configuration that should be
shared with old git, and I assume anyone using %C for the first time
would be looking at the manual, which could warn her.
Cheers,
Jonathan
--
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