Force "git status" to output color on the terminal (inside a script)

Question

EDIT:

I would like to make a recommendation that parsing colors is a generally ill-conceived idea.

Part of why i wanted it was so I can both parse it and pass it along in my own script output. This is... okay, but it would probably be saner to use porcelain or some such and re-build the colored parts myself!

Original question follows.

I like to see color because my scripting is robust enough (so far) to handle the color codes. It does seem like I'm going against the grain here, but I honestly don't see what the big deal is about having to parse stuff like escape codes in scripts. If colors help for interactive use, why wouldn't they help in script use where I might be aggregating data and crunching even more data than I would manually? Wouldn't colors be even more important?

Anyway, I have a neat little shell script I wrote that munges git status output, and i'm just looking to make this script keep the colors intact. My global git config is set so that the lists of changed and untracked files show up in color in the git status. Unfortunately unlike git diff there is no option for forcing color for git status that I can find.

To be abundantly clear, this is the issue:

$ git status

produces perfect output, but (excerpt from my script follows)

git status | sed "s/^#/\x1b[34m#[0m/"

produces no colored git status output, and you can even see here that I'm explicitly converting the leading hash-characters to blue because it helps highlight the different regions of output from my script.

Does anyone know how to get it to put out the colors? Is there maybe a standard program I can use that can be used as a "fake terminal" STDIN/STDOUT pipe? I am in fact also working on a pty pseudoterminal tool so I could certainly make use of that for this purpose, but it's a rather heavy-handed solution (and not ready for use yet as I haven't finished building it).

One issue with parsing colour codes to extract meaningful data for scripts is that a different user may have configured different colours in their config file. To avoid the issues that would cause, git offers the --porcelain option for various commands, which should provides a format that is easier to parse and less prone to change between environments. — joeytwiddle
To add to @joeytwiddle's comment, as a design note, it's a bad idea to encode status information as only color since some people have various kinds of color blindness (red-green is the most common but there is also blue-yellow, and more; for details see nei.nih.gov/health/color_blindness/facts_about). It affects roughly 10% of humans! Always make sure that there is some way other than mere color to extract necessary information. — torek

joeytwiddle joeytwiddle · Accepted Answer · 2013-08-18T23:21:19

To avoid changing your git config, you can enable colour just for the current command by passing a config variable with -c.

For the status command, the variable is color.status:

    git -c color.status=always status | less -REX

For diff, show, log and grep commands, the variable is color.ui:

    git -c color.ui=always diff | less -REX

Note that -c must come before the status or diff argument, and not after.

Alternatively, for diff, show, log and grep commands, you can use --color=always after the command:

    git diff --color=always | less -REX

Note: As Steven said, if you are trying to extract meaningful data, then instead of parsing colours to extract meaning, you can use --porcelain to get more parser-friendly output.

    git status --porcelain | awk ...

Then if you wanted, you could reintroduce colours later.

To get the user's configured colours, you can use git config --get-colour:

    reset_color="$(tput sgr0)"
    remote_branch_color="$(git config --get-color color.branch.remote white)"

    echo "Pushing to ${remote_branch_color}${branch_name}${reset_color}"

Some more examples here.

Force "git status" to output color on the terminal (inside a script)

3 Answers