Some colors are not rendered on ANSI-aware Windows 10 CMD

[rahul-ramadas]

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

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.12.2.windows.1
built from commit: 212247dd6345c820deeae61fcdf2f10cea10525a
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.14393]

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

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: CRLFAlways
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

None. I was able to reproduce this issue on an almost vanilla install of Windows.

Details

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

CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git config --global color.branch.upstream #FF00FF
git branch -a -vv

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

The upstream branch ref name is expected to be fuchsia colored.

• What actually happened instead?

The upstream branch ref name is not colored.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

Not related to repository.

• More details?

I think with Windows 10, ANSI escape codes for coloring are expected to work. In the attached screenshot, you can see that the output of git branch -a -vv does not have all the coloring, but if I force ANSI codes to be emitted using --color, redirect the output to a file, and then dump the file, the output is colored properly, confirming that the terminal knows how to interpret the escape codes correctly. Git may be swallowing the escape codes because it thinks CMD does not support them.

[dscho]

At the moment, there are no contributors working on more complete color support. If you have time to work on this, that would be awesome. If not, it may not even happen...

I think with Windows 10, ANSI escape codes for coloring are expected to work.

I just recompiled Git for Windows locally, disabling the winansi_init() function that starts that thread which colors Git's output on the console, and then ran git show --color. The output is not colorized, but contains the ugly characters �[33mcommit ffb791af409a00b8ccc121b0b2824fb2b537d3d5�[m. So i am afraid that ANSI escape codes do not work out of the box on Windows 10. I guess that type has some special provision to interpret them.

[rahul-ramadas]

Did you enable the enhanced console? Uncheck Use legacy console.

If I have Use legacy console checked, then type emits garbage characters as you described (the escape codes).

[dscho]

Did you enable the enhanced console?

No.

[sschuberth]

AFAIK Windows 10's conhost.exe only intercepts ANSI sequences if SetConsoleMode is called with ENABLE_VIRTUAL_TERMINAL_PROCESSING from the program writing to the console, see here.

[Sidneys1]

Some commands still seem to entirely un-set ENABLE_VIRTUAL_TERMINAL_PROCESSING and do not restore the setting afterwards (see below screenshot of git status vs git fetch). This appears to happen with any command that uses the built-in less paging functionality.

[dscho]

I will re-open this ticket once anybody is interested in working on it.