On Wed, May 31, 2017 at 11:33:31AM -0700, Irving Rabin wrote: > Specifically, if the field is supposed to be white, it doesn't mean it > should be literally 0xFFFFFF. It should be the color that I have > configured as White color for my console emulator. > > I like light-screen terminals, and I configure my ANSI colors in the > way that they are clearly visible on the background and clearly > distinct between themselves. In my terminal settings background is > light-yellow, Black is black, Yellow is brown, Red is dark red, > Magenta is purple and White is dark gray. I set it once and I can use > it everywhere - all Unix commands work correctly, I can edit > highlighted source code in Vim, and all my color settings are > respected. Git outputs ANSI color codes, which are interpreted by your terminal. You _can_ configure Git to send 24-bit color codes if your terminal supports it, but by default it uses the traditional set of limited color and attribute codes. What does running the following snippet in your shell look like? -- >8 -- while read name code; do printf '\033[%sm%s\033[m\n' "$code" "$name" done <<-\EOF normal bold 1 red 31 green 32 yellow 33 blue 34 magenta 35 cyan 36 bold-red 1;31 bold-green 1;32 bold-yellow 1;33 bold-blue 1;34 bold-magenta 1;35 bold-cyan 1;36 EOF -- 8< -- If any of the colors are not what you expect, is there a pattern? E.g., I wouldn't be surprised if "bold" shows up as bright white. In many modern terminal emulators, the bold variants need to be configured separately from the non-bold ones, and default to lighter variants of their non-bold counterparts. The solution there would be to check your terminal emulator config. If it does all look as you'd expect, try adding "| less -R" to the end of the "done <<-\EOF" line. Most of Git's output goes through that pager (though I _think_ it's mostly just passing through the ANSI codes, so it wouldn't have any effect). -Peff