summaryrefslogtreecommitdiff
path: root/contrib/contacts
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2017-07-13 11:09:32 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2017-07-13 12:42:51 -0700
commit11b087adfd469ca597f1d269314f8cad32d0d72f (patch)
treee0474bf5f8703ab737ca9fd59cae31c0813cc652 /contrib/contacts
parentpretty: respect color settings for %C placeholders (diff)
downloadtgif-11b087adfd469ca597f1d269314f8cad32d0d72f.tar.xz
ref-filter: consult want_color() before emitting colors
When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'contrib/contacts')
0 files changed, 0 insertions, 0 deletions