for-each-ref --format doesn't display ANSI background color '8' anymore.

• I was not able to find an open or closed issue matching what I'm seeing

Setup

Git version: Git-2.35.1.2 64-bit

$ git --version --build-options

git version 2.35.1.windows.2
cpu: x86_64
built from commit: 5437f0fd368c7faf1a0b5e1fef048232c1f2a3e6
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.19043.1526]

 - What options did you set as part of the installation? Or did you choose the
   defaults?

Editor Option: Notepad++
Custom Editor Path:
Default Branch Option:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Git Pull Behavior Option: Merge
Use Credential Manager: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

The issue I'm observing is terminal agnostic. (Run in cmd and PowerShell).

The test command that I've been using to check this problem is:

git for-each-ref --sort=committerdate refs/heads/ --format="%(color: red 8)%(author)"

• What did you expect to occur after running these commands?

This should output text with red foreground and a gray background, but the background is no longer present.
This behavior worked in git version 2.25.1.windows.1

2.25.1.windows.1
cpu: x86_64
built from commit: cceb69da75b4906bb04cfb3a2f7f37b12b985ec3
sizeof-long: 4
sizeof-size_t: 8

• What actually happened instead?

It prints the text out with red foreground and no background (matches the background).

I attempt to work around the issue by supplying a hex color, but it doesn't seem that that works with for-each-ref --format

git for-each-ref --sort=committerdate refs/heads/ --format="%(color: red #808080)%(author)"

Although the hex color does work with something like: git log --format="%C(red #808080)%an%C(reset)")

[dscho]

Could you test with the latest snapshot? There have been quite a few patches that could potentially fix this.

If the snapshot does not fix it, it might be worth bisecting through the snapshots to figure out which is the oldest one exposing that problem.

I checked with the latest snapshop (158a30d60b1676f8e52457478eaf7b4db95e9949), it still has that same issue.

I'm not sure when I might have time to bisect the snapshots. But Git-2.35.1.2 64-bit is broken while 2.25.1.windows.1 works.
Doesn't this tell us likely that the problem is older and thus won't be in a recent snapshot? Maybe you're suggesting using the snapshots to go in between the release that doesn't exhibit the problem and one that does. (I have not yet bisected the official release to find those two releases).

So I take it you don't see this issue if you use the same command?

[dscho]

But Git-2.35.1.2 64-bit is broken while 2.25.1.windows.1 works.
Doesn't this tell us likely that the problem is older and thus won't be in a recent snapshot?

Indeed it tells us that, but that range is too broad! A lot has happened in the last two years. It would be really helpful to narrow it down much more, to have a better idea where the culprit could potentially lie, ideally seeing a "smoking gun" in a specific commit.

So I take it you don't see this issue if you use the same command?

I just tried it with v2.14.2 and v2.35.1(2) and can reproduce, yes. But still, the search space is too vast, and since I will most likely spend hours trying to fix this even once the search space has been whittled down to a specific snapshot exhibiting the behavior for the first time, I am rather unwilling to also be the one to whittle it down 😃

Okay. If I find time to whittle it down, should I comment here on this issue? Or shall I create a separate issue on the project?

[dscho]

If I find time to whittle it down, should I comment here on this issue?

Please comment here.

Seeing as I closed this by accident, I guess that sent a message that further comments would not be welcome. But it was an innocent mistake on my part.

[dscho]

So I think I figured it out.

git log automatically spawns a pager called less.exe, which is an MSYS program and hence uses the MSYS2 runtime to emulate ANSI sequences. If you call git -P log [...] to prevent that pager from being spawned, the background color will not be set.

Likewise, if you run git -p for-each-ref [...], it will spawn the pager, and the background color will be set.

The main reason why things do not work as expected without a pager is that Git for Windows has not gained support for the relatively new Virtual Terminal Sequences support. In #4700, I propose a patch that adds said support. With this, the background color will work as expected even without the pager.