[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to make git colorise output with parallel?

From: Ernst, Kevin
Subject: Re: How to make git colorise output with parallel?
Date: Thu, 2 Jul 2020 13:11:01 +0000

Hi Gabriel, hope you're well.

My answer is below the quoted part; you may have to click a "…" to 
reveal it, depending on your email client.

On 01.07.20 at 22:13, Gabriel Ostrolucky wrote:
> fd '.git$' --hidden -t d|parallel git -C {//} pull
> Why does this happen, and what can I do to preserve the git colours?

Unix programs can check if their output will be sent to an interactive 
terminal, and, based on that, they can choose whether or not to display 
colours. In Bash, for example, this is done with a test like |[[ -t 1 
]]|, for file descriptor #1 (standard out).

Reason being, you would typically not want the ANSI escape sequences 
<> producing the colours 
to foul up the output if you’re going to redirect to a file, or process 
it in a pipeline with other tools (|git status --porcelain | grep …|, 
for example).

I’m not familiar enough with the internals of Parallel enough to say 
definitively, but I imagine this test would fail for parallel tasks, 
causing them to revert to non-colourised output.

As you know, for the situations where you, the human, know that the 
ultimate output destination will be a terminal that /can/ display 
colour, many tools provide a command-line option to force colour on even 
if standard out is not a terminal/; /for example,// |fd -c always|. You 
can then pipe into |less -R| (“raw”), which interprets the ANSI escapes, 
to test that this has worked.

Git doesn’t have a straightforward |-C| or |--color=always| option 
documented in the man page, but it /does/ have the option to set a 
one-off configuration variable:

    # ref.
    git -c color.status=always status | less -R
    git -c color.ui=always log | less -R

Note that the config option is different for |status| versus all the 
other subcommands.

If your instinct is to |git config --global color.ui always|, I would 
resist that urge. As a demonstration of why, try this in a new terminal 

    # assuming Bash shell
    unset LESS
    unalias less
    git -c color.ui=always log | less

The |unset| and |unalias| are to remove any customizations which may set 
|less|‘s “raw” (|-R|) option on by default. That way you’ll get to /see/ 
the ANSI escape sequences in the output, like this:

    ESC[33mcommit 49a6c68debfc2b7327b4ada89d908718d0181e60ESC[m
    Author: Kevin Ernst⋮

That’s usually not what you want when you’re piping text streams into 
some other tool (/e.g., /|cut|, |sed|, |awk|) for downstream processing, 
which is why every well-behaved Unix tool defaults to not displaying 
colours when the output is not a terminal.

Hope this helps!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]