path: root/t/
diff options
authorJeff King <>2017-07-13 15:08:46 (GMT)
committerJunio C Hamano <>2017-07-13 19:42:51 (GMT)
commit18fb7ffc3dc9df081c241d6b7105b4058d5746d3 (patch)
tree260ba52308d914a9dd7464aeb92348cd370e3ced /t/
parentd75dfb1089d471501f6042341bed647525f6e293 (diff)
pretty: respect color settings for %C placeholders
The color placeholders have traditionally been unconditional, showing colors even when git is not otherwise configured to do so. This was not so bad for their original use, which was on the command-line (and the user could decide at that moment whether to add colors or not). But these days we have configured formats via pretty.*, and those should operate correctly in multiple contexts. In 3082517 (log --format: teach %C(auto,black) to respect color config, 2012-12-17), we gave an extended placeholder that could be used to accomplish this. But it's rather clunky to use, because you have to specify it individually for each color (and their matching resets) in the format. We shied away from just switching the default to auto, because it is technically breaking backwards compatibility. However, there's not really a use case for unconditional colors. The most plausible reason you would want them is to redirect "git log" output to a file. But there, the right answer is --color=always, as it does the right thing both with custom user-format colors and git-generated colors. So let's switch to the more useful default. In the off-chance that somebody really does find a use for unconditional colors without wanting to enable the rest of git's colors, we provide a new %C(always,...) to enable the old behavior. And we can remind them of --color=always in the documentation. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
Diffstat (limited to 't/')
0 files changed, 0 insertions, 0 deletions