On Fri, Dec 29 2017, [email protected] jotted:
> My ~/.gitconfig sets color.ui=never, which should prevent attempts
> at colouring output from all git commands. I do not have any git
> configuration enabling colour in any situation (such as for specific
> commands). But when a git bisect completes, the output identifying
> the first bad commit includes escape sequences to colour the "commit
> 3e6..." line yellow. Excerpt of strace output (with many irrelevant
> lines omitted):
>
> 23851 write(1, "3e6fc602e433dbd76941ac0ef7a438a77fbe9a05 is the first bad
> commit\n", 65) = 65
> 23851 open("/home/zefram/.gitconfig", O_RDONLY) = 3
> 23851 read(3, "[user]\n\tname = Zefram\n\temail =
> [email protected]\n\tsigningkey = 0x8E1E1EC1\n\n[color]\n\tui = never\n", 4096)
> = 93
> 23851 write(1, "\33[33mcommit
> 3e6fc602e433dbd76941ac0ef7a438a77fbe9a05\33[m\n", 56) = 56
>
> Given the configuration, that line should be free of escape sequences.
>
> I'm mainly using git 2.1.4 via Debian, but I've also
> reproduced this problem with the latest from git.git (commit
> 1eaabe34fc6f486367a176207420378f587d3b48, tagged v2.16.0-rc0).
This issue is a bug, but has nothing do do with bisect per-se, but is a
bug in diff-tree, compare these two:
git -c color.ui=never diff-tree --pretty --stat HEAD
git -c color.ui=never show --pretty --stat HEAD
diff-tree will incorrectly show colored output here despite
ui.color=never.