git 分支漂亮格式 '%C(always/auto)'

Question

I'm trying to create an alias for a particular view of my git branches, with the usual verbose data plus some extra. (Datetime; I'm also sorting by date.) This is possible with a custom format string, but it loses the default coloring from git branch -v ; the active branch doesn't get highlighted in green and other coloring like upstreams doesn't show up either. It looks to me from git docs like this should be fixed by adding %C(always) as a prefix to the format string, but this doesn't seem to work:

git branch --format=:%C(always) %(committerdate:short) %(refname:short) %(contents:lines=1)"

just displays

%C(always) 2022-08-23 foo/bar testing Token
%C(always) 2022-08-26 seethefnords fix validation

with no color. What is wrong here?

(Also, just incidentally, is it possible to get the smart alignment back in a custom format string?)

Answer 1

just displays

%C(always) 2022-08-23 foo/bar testing Token

Then the first thing to check is your Git version.

%C(always) was introduced with Git commit 4261775 , Git 2.22 (Q2 2019).
Which means you might be using an older Git version.

git version

Answer 2

TL;DR: for git log , you may want %C(always,red) for instance, or you may just want to use git log --color=always directly here. Meanwhile git branch uses git for-each-ref formats, which simply don't support the same options (but git branch and git for-each-ref do have --color=always ).

Longer

The %C(stuff,goes,here) formatting directive is indeed a color-changing directive, but it does not work the way you think here.

Color, in Git, is handled in a sort of complicated way. First, Git assumes an ANSI-style terminal emulator that allows ESC [ <digits and semicolons sequence> m "escape sequences" that control attributes like color, boldface, underline, blinking, italics (if available), and so on. A set of eight standard colors are available with nummeric values 0, 1, 2, 3, 4, 5, 6, and 7: adding 30 (to get, eg, 33) sets a foreground color, so that:

printf "\033[31mred \033[34mblue\033[m\n"

prints the words red blue in red and blue respectively (the \033[m at the end cancels the coloring). Adding 40 instead of 30 obtains a background color instead of a foreground color. These can be combined:

printf "\033[37;41mred \033[44mblue\033[m\n"

prints the words red blue again, but this time the text is white and the background of each word is first red, then blue (the blank in between is also red).

If you like, you can specify these colors with these names: this is very portable these days. Or, you can use raw color values, if your terminal emulator allows them. The details for the terminal emulation are covered pretty well here , with some of the Git-side details for selecting such colors covered in How to use ANSI 256-color in.gitconfig .

Now, the thing about color—whether specified by a directive or not—is that Git will only emit color-changing ANSI escape sequences when this is enabled . It is enabled when:

• the output is going to a terminal and the enablement is auto and there's a color, or
• it's forced on

and it's disabled whenever it's forced off or there's no color available for that particular mode or output is piped .

The %C directive in git log can take a color name, perhaps even parenthesized, so %C(red)red%C(reset) puts the word red in red-foreground (with ESC [ 31 m) and then resets color mode (with ESC [ m), but only if color is enabled .

The %C(always) modifier applies only to the color also in the parentheses . That is, you'd write %C(always,red)red%C(always,reset) to override the lack of --color=always as a command line option.

Adding --color=always is a lot easier and is the way to go if you have that option.

(Also, just incidentally, is it possible to get the smart alignment back in a custom format string?)

I'm not entirely sure what you mean by "smart alignment" here, but aside from %w , %< , and %> directives, there's not a lot of control here. Some of the built in formats cannot (currently) be expressed as percent-escapes. This has very gradually improved over time: Git 1.5 couldn't do very many, Git 2.30 can do a fair number of them.

The git for-each-ref plumbing command, and its git branch and git tag porcelain variants, don't have as many formatting directives. In particular there are no color ones at all (though there probably should be).

Answer 3

Here's a short answer: git branch does not obey the pretty format directives you've linked. Those are for git log only.