Git Color UI support for 256 Colors?

Question

I am trying to colour my Git output using my native XTerm 256 color palette. Is there anyway to do this? I can't seem to get it to work.

for example in .gitconfig.

[color]
  ui = auto
[color 'branch']
  local = colour33
  remote = colour46
  current = colour27

Etc.
I know this formatting works when you specify the various basic color terms; cyan, magenta, yellow, and attributes; dim, bright, ul, bold, etc.
But I just can't find anything in regards to using the full color palette available to a 256color terminal, without actually changing the 8 basic color terms themselves, in the actual pallete.
There isn't anything in the documentation or manpages that I can find either.
I know different programs seem to use different syntax for specifying color, so I may just be using the wrong syntax or I am the only one who has ever wanted to do such a thing.

I am assuming git-config will only support those basic 8 colors with various attributes based on what the git-config man page is saying, so if this is not possible, is there a way to change those colors, in the terminals color palette BUT only for one program, like in this situation, Git? Maybe a perl script that exports those values only when git-config is referencing them, but unsets them soon as git-config is finished?

And no this is not too much trouble than its worth. I love my eyecandy in a terminal, and id do it myself if I could figure out a resource that explains something similar.

Coon

Note: if 256 colors are not enough, git 2.3.0 (February 2015) will allow 24-bits colors! See my edited answer below – Evasion

Answer 1

The syntax for the color is: [fg [bg]] [attr]...

As for the colors, you can use the named ones (normal, black, red, green, yellow, blue, magenta, cyan, and white) or just a number of the color in the 256 palette without any prefix.

The supported attributes are: bold, dim, ul, blink, and reverse.

So your configuration might look like this (tested with git 1.8.5.3):

[color "branch"]
    local = 33 
    remote = 46
    current = 27

I have taken a look into the git source code to find the answer.

Nicholle

Btw, to test the color, you can use something like echo $(git config --get-color "" "120 bold reverse") color test $(git config --get-color "" reset) – Metheglin

Answer 2

Note that:

---

• the support for colors is now documented (January 2015, Git 2.2.2, commit 0edad17 ) :

docs: describe ANSI 256-color mode

Our color specifications have supported the 256-color ANSI extension for years, but we never documented it.

git config man page now includes:

Colors (foreground and background) may also be given as numbers between 0 and 255;
these use ANSI 256-color mode (but note that not all terminals may support this)

---

• using numerical value for the color will be more robust with Git 2.2.2 (January 2015).
  See commit d0e08d6 from Jeff King (peff):

config: fix parsing of "git config --get-color some.key -1"

Most of git-config's command line options use OPT_BIT to choose an action, and then parse the non-option arguments in a context-dependent way. However, --get-color and --get-colorbool are unlike the rest of the options, in that they are OPT_STRING, taking the option name as a parameter.

This generally works, because we then use the presence of those strings to set an action bit anyway. But it does mean that the option-parser will continue looking for options even after the key (because it is not a non-option; it is an argument to an option). And running:

git config --get-color some.key -1

(to use "-1" as the default color spec) will barf, claiming that "-1" is not an option.
Instead, we should treat --get-color and --get-colorbool as action bits, just like --add, --get, and all the other actions, and then check that the non-option arguments we got are sane.
This fixes the weirdness above, and makes those two options like all the others.

This "fixes" a test in t/t4026-color.sh, which checked that feeding "-2" as a color should fail (it does fail, but prior to this patch, because parseopt barfed, not because we actually ever tried to parse the color).

This also catches other errors, like:

git config --get-color some.key black blue

which previously silently ignored "blue" (and now will complain that you gave too many arguments).

There are some possible regressions, though.
We now disallow these, which currently do what you would expect:

  # specifying other options after the action
  git config --get-color some.key --file whatever

  # using long-arg syntax
  git config --get-color=some.key

---

If 256 colors are not enough, you can import even more colors.
See commit 17a4be2 (Git 2.3.0, Q1 2015)

parse_color: support 24-bit RGB values

Some terminals (like XTerm) allow full 24-bit RGB color specifications using an extension to the regular ANSI color scheme.
Let's allow users to specify hex RGB colors, enabling the all-important feature of hot pink ref decorations:

git log --format="%h%C(#ff69b4)%d%C(reset) %s"

Evasion