Don't colorize the refs with git log --pretty when --no-color is specified

Question

I'm working with Git, using Windows 7, PowerShell, and Posh-Git. I have the following alias setup:

ls = log --pretty=tformat:"%C(yellow)%h\\ %C(green)[%ad]%C(cyan)\\ <%cn>\\ %C(reset)%s%C(auto)%d"

The problem was that when I pipe the output to clip.exe to copy it to the clipboard, it also copies some characters for the colors. A little reading and I found you could add "auto," so that it would use the default colors if the --no-color option is specified. So now I have:

ls = log --pretty=tformat:"%C(auto,yellow)%h\\ %C(auto,green)[%ad]%C(auto,cyan)\\ <%cn>\\ %C(auto,reset)%s%C(auto)%d"

The problem I now have is the last bit of the output showing the refs. I have the color set to auto so that git will apply the default colors for branches and tags, but can't figure out how to get it to respect the --no-color option. If I set it to %C(auto) the colors show all the time. I tried %C(auto,auto) and that works with --no-color, but without it git complains:

error: invalid color value: auto
fatal: unable to parse --pretty format

Answer 1

can't figure out how to get it to respect the --no-color option.
If I set it to %C(auto), the colors show all the time.

This will be fixed in git 2.9.x+ (Q3 2016)

See commit b15a3e0 (27 May 2016) by Edward Thomson (ethomson).
^{(Merged by Junio C Hamano -- gitster -- in commit 1b3d14c, 20 Jun 2016)}

format_commit_message: honor color=auto for %C(auto)

git-log(1) documents that when specifying the %C(auto) format placeholder will "turn on auto coloring on the next %placeholders until the color is switched again."

However, when %C(auto) is used, the present implementation will turn colors on unconditionally (even if the color configuration is turned off for the current context - for example, --no-color was specified or the color is auto and the output is not a tty).

Update format_commit_one to examine the current context when a format string of %C(auto) is specified, which ensures that we will not unconditionally write colors.
This brings that behavior in line with the behavior of %C(auto,<colorname>), and allows the user the ability to specify that color should be displayed only when the output is a tty.

This is what you see with git-for-windows 2.9.0

But with a more recent 2.9.x+ git version, --no-color does work: