How to colorify git errors, warnings and fatal messages?

Question

When troubleshooting git issues of users, I keep running into people not noticing error/warning messages from git, and then burning their fingers. Is there any way to colorify errors and warnings git outputs?

Boom

+1, good question. Most people just don't know how to read. – Ezar

On what Operating System / git client? – Christa

DaveShaw: regular console git client, on any OS. – Boom

Answer 1

With Git 2.18 (Q2 2018), you now have a better documentation of the settings to colorize push errors/hints.

See commit 79f62e7 (21 Apr 2018) by Johannes Schindelin (dscho).
^{(Merged by Johannes Schindelin -- dscho -- in commit 79f62e7, 24 Apr 2018)}

push: colorize errors

This is an attempt to resolve an issue I experience with people that are new to Git -- especially colleagues in a team setting -- where they miss that their push to a remote location failed because the failure and success both return a block of white text.

An example is if I push something to a remote repository and then a colleague attempts to push to the same remote repository and the push fails because it requires them to pull first, but they don't notice because a success and failure both return a block of white text. They then continue about their business, thinking it has been successfully pushed.

This patch colorizes the errors and hints (in red and yellow, respectively) so whenever there is a failure when pushing to a remote repository that fails, it is more noticeable.

---

With Git 2.19 (Q3 2018), The sideband code learned to optionally paint selected keywords at the beginning of incoming lines on the receiving end.

See commit bf1a11f (07 Aug 2018) by Han-Wen Nienhuys (hanwen).
Helped-by: Jonathan Nieder (artagnon).
^{(Merged by Junio C Hamano -- gitster -- in commit d280170, 20 Aug 2018)}

sideband: highlight keywords in remote sideband output

The colorization is controlled with the config setting "color.remote".

Supported keywords are "error", "warning", "hint" and "success".
They are highlighted if they appear at the start of the line, which is common in error messages, eg.

ERROR: commit is missing Change-Id

The Git push process itself prints lots of non-actionable messages (eg. bandwidth statistics, object counters for different phases of the process).
This obscures actionable error messages that servers may send back.
Highlighting keywords in the sideband draws more attention to those messages.

The background for this change is that Gerrit does server-side processing to create or update code reviews, and actionable error messages (eg. missing Change-Id) must be communicated back to the user during the push.
User research has shown that new users have trouble seeing these messages.

The highlighting is done on the client rather than server side, so servers don't have to grow capabilities to understand terminal escape codes and terminal state.
It also consistent with the current state where Git is control of the local display (eg. prefixing messages with "remote: ").

The highlighting can be configured using color.remote.<KEYWORD> configuration settings.
Since the keys are matched case insensitively, we match the keywords case insensitively too.

Finally, this solution is backwards compatible: many servers already prefix their messages with "error", and they will benefit from this change without requiring a server update.
By contrast, a server-side solution would likely require plumbing the TERM variable through the git protocol, so it would require changes to both server and client.

---

Note: Use Git 2.21 (Q1 2019): Lines that begin with a certain keyword that come over the wire, as well as lines that consist only of one of these keywords, ought to be painted in color for easier eyeballing, but the latter was broken ever since the feature was introduced in 2.19, which has been corrected.

See commit 1f67290 (03 Dec 2018) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 20b3bc1, 14 Jan 2019)}

sideband: color lines with keyword only

When bf1a11f (sideband: highlight keywords in remote sideband output, 2018-08-07) was introduced, it was carefully considered which strings would be highlighted.
However 59a255a (sideband: do not read beyond the end of input, 2018-08-18) brought in a regression that the original did not test for.
A line containing only the keyword and nothing else ("SUCCESS") should still be colored.

Build

Nice @VonC! The respective settings color.advice, color.push and color.transport all default to color.ui, that defaults to auto, so all of these are enabled by default. Finally! – Boom

ubuntu still does not have that newer git version. to install it i've refered to unix.stackexchange.com/questions/33617/… – Nadeen

@Nadeen Yes, I have used the Git installation with ppa myself before indeed: https://mcmap.net/q/13279/-unknown-option-allow-unrelated-histories-39 for instance. – Build

If I'm too lazy to read error messages what makes you think I'm going to read this wall of text? This answer could be improved by summarizing what actions to take to get highlighting enabled. I'm on git 2.25.1 and still no color highlighting of error messages. – Kickback

@RobMosher True, I tried git -c color.pager=true -c color.push=always -c color."push".error=red push xxx, and no color as well, on Widows (Git for Windows 2.39.1) or WSL2 Ubuntu (Git 2.25.1). On which OS/environment are you? – Build

Answer 2

Since I didn't find a suitable way to color error messages, my solution is to add an additional warning when git returns an error code (!=0).

To do it, add this to your ~/.bashrc or ~/.bash_profile

# Wrap git. On errors, print an additional line in red.
git(){
    command git "$@"
    local exitCode=$?
    if [ $exitCode -ne 0 ]; then
        printf "\033[0;31mERROR: git exited with code $exitCode\033[0m\n"
        return $exitCode
    fi
}

Here is the result:

Note that coloring stderr in red does not work very well because git logs many things in stderr, not only errors. And some errors are output in standard output.

Grigri

Beautiful, thank you for posting this solution! – Laundry

Answer 3

There is no git buit-in way to do that. Git just prints errors to STDERR and doesn’t care about the fatality of the error or anything. What you can do is color STDERR red. How to do this has been asked on on ServerFault: https://serverfault.com/questions/59262/bash-print-stderr-in-red-color

There are three basic options:

1. Run your command like this:

   *git-command* 2> >(while read line; do echo -e "\e[01;31m$line\e[0m" >&2; done)
   

2. Use a wrapper script (See ServeFault for those), and run commands like

   mywrapper *git-command*
   

3. Install stderred. This will allow you to make the effect permanent, without modifying your command line. Not sure whether this will work on windows, though.

Muckworm

Coloring stderr in red does not work for me: git logs many things in stderr, not only errors. And some errors are output in standard output. – Grigri

Answer 4

You can use the color config section of git.

For more information and examples see http://git-scm.com/book/en/Customizing-Git-Git-Configuration#Colors-in-Git or the second part of http://blog.philippmetzler.com/?p=15

example: (add to your .gitconfig)

[color]
     interactive = always
[color "interactive"]
     error = red bold

Roundelay

Did you try this out yourself? Because as far as I know, that doesn't color at least error/fatal. – Boom

I think this only applies to things like git add --interactive. – Perot

The most USEFUL color change is really to just turn them off. It's just not a good tool if you have a black background. git config --global color.ui false – Lema