How to color the Git console?

Question

I recently saw that the git console in Windows is colored, e.g. Green for additions, red for deletions, etc. How do I color my git console like tha

Answer 1

Well, if you are not satisfied with the default setting, you can use ANSI escape code to help you set the color, and if you want to modify some text, you can write bash to help you. see as below:

Eaxmplae

# .gitconfig

[alias]
    st-color = "!f() { \
        echo -n -e '\\033[38;2;255;0;01m\\033[4m' ;\
        git status -s | grep ' D' | \
        sed -e 's/^ ./DELETE:/' ; \
        echo -n -e '\\033[m' ;\
        \
        echo -n -e '\\033[48;2;128;128;128m' ;\
        echo -n -e '\\033[38;2;0;255;01m' ;\
        git status -s | grep ' [AM]' | \
        sed -e 's/^ ./NEW OR MODIFY:/' ; \
        echo -n -e '\\033[m' ;\
        \
        echo -n -e '\\033[38;2;255;0;255m' ;\
        echo Rename ;\
        git status -s | grep 'R ' | \
        sed -e 's/^..//' ; \
        echo -n -e '\\033[m' ;\
    }; f"

demo

Explanation

1. you can write the long script on .gitconfig use the syntax as below:

   [alias]
       your-cmd = !f() { \
           \
       }; f"
   

2. echo -n -e (see more echo)

   • -n = Do not output a trailing newline.
   • -e Enable interpretation of the following backslash-escaped

3. \\033[38;2;255;0;0m\\033[4m (see more SGR parameters)

   • \\033[38;2;255;0;0m : 38 mean fore color. 255;0;0 = Red | r;g;b
   • \\033[4m : underline

4. grep : The grep command is used to search text.

5. sed -e 's/be_replace_string/new_string/' replace string to new string.

Answer 2

For example see https://web.archive.org/web/20080506194329/http://www.arthurkoziel.com/2008/05/02/git-configuration/

The interesting part is

Colorized output:

git config --global color.branch auto
git config --global color.diff auto
git config --global color.interactive auto
git config --global color.status auto

Answer 3

In your ~/.gitconfig file, simply add this:

[color]
  ui = auto

It takes care of all your git commands.

Answer 4

refer here: https://nathanhoad.net/how-to-colours-in-git/

steps:

1. Open ~/.gitconfig for editing

   vi ~/.gitconfig

2. Paste following code:

   [color]
     ui = auto
   [color "branch"]
     current = yellow reverse
     local = yellow
     remote = green
   [color "diff"]
     meta = yellow bold
     frag = magenta bold
     old = red bold
     new = green bold
   [color "status"]
     added = yellow
     changed = green
     untracked = cyan
   

3. Save the file.

Just change any file in your local repo and do

git status

Answer 5

As noted by @VonC, color.ui defaults to auto since Git 1.8.4

---

From the Unix & Linux Stackexchange question How to colorize output of git? and the answer by @Evgeny:

git config --global color.ui auto

The color.ui is a meta configuration that includes all the various color.* configurations available with git commands. This is explained in-depth in git help config.

So basically it's easier and more future proof than setting the different color.* settings separately.

In-depth explanation from the git config documentation:

color.ui: This variable determines the default value for variables such as color.diff and color.grep that control the use of color per command family. Its scope will expand as more commands learn configuration to set a default for the --color option. Set it to always if you want all output not intended for machine consumption to use color, to true or auto if you want such output to use color when written to the terminal, or to false or never if you prefer git commands not to use color unless enabled explicitly with some other configuration or the --color option.

Answer 6

With Git 2.18, you have more control on how you want to specify colors in the console.
The "git config" command uses separate options e.g. "--int", "--bool", etc. to specify what type the caller wants the value to be interpreted as.

A new "--type=<typename>" option has been introduced, which would make it cleaner to define new types.

See commit fb0dc3b (18 Apr 2018), and commit 0a8950b (09 Apr 2018) by Taylor Blau (ttaylorr).
^{(Merged by Junio C Hamano -- gitster -- in commit e3e042b, 08 May 2018)}

builtin/config.c: support --type=<type> as preferred alias for --<type>

git config has long allowed the ability for callers to provide a 'type specifier', which instructs git config to (1) ensure that incoming values can be interpreted as that type, and (2) that outgoing values are canonicalized under that type.

In another series, we propose to extend this functionality with --type=color and --default to replace --get-color.

However, we traditionally use --color to mean "colorize this output", instead of "this value should be treated as a color".

Currently, git config does not support this kind of colorization, but we should be careful to avoid squatting on this option too soon, so that git config can support --color (in the traditional sense) in the future, if that is desired.

In this patch, we support --type=<int|bool|bool-or-int|...> in addition to --int, --bool, and etc.
This allows the aforementioned upcoming patch to support querying a color value with a default via --type=color --default=..., without squandering --color.

We retain the historic behavior of complaining when multiple, legacy-style --<type> flags are given, as well as extend this to conflicting new-style --type=<type> flags. --int --type=int (and its commutative pair) does not complain, but --bool --type=int (and its commutative pair) does.

So before you had --bool and --int, now (documentation):

--type <type>

'git config' will ensure that any input or output is valid under the given type constraint(s), and will canonicalize outgoing values in <type>'s canonical form.

Valid <type>'s include:

• 'bool': canonicalize values as either "true" or "false".
• 'int': canonicalize values as simple decimal numbers. An optional suffix of 'k', 'm', or 'g' will cause the value to be multiplied by 1024, 1048576, or 1073741824 upon input.
• 'bool-or-int': canonicalize according to either 'bool' or 'int', as described above.
• 'path': canonicalize by adding a leading ~ to the value of $HOME and ~user to the home directory for the specified user. This specifier has no effect when setting the value (but you can use git config section.variable ~/ from the command line to let your shell do the expansion.)
• 'expiry-date': canonicalize by converting from a fixed or relative date-string to a timestamp. This specifier has no effect when setting the value.

--bool::
--int::
--bool-or-int::
--path::
--expiry-date::
  Historical options for selecting a type specifier. Prefer instead `--type`,
(see: above).

---

Note that Git 2.22 (Q2 2019) explains "git config --type=color ..." is meant to replace "git config --get-color", but there is a slight difference that wasn't documented, which is now fixed.

See commit cd8e759 (05 Mar 2019) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit f6c75e3, 20 Mar 2019)}

config: document --type=color output is a complete line

Even though the newer "--type=color" option to "git config" is meant to be upward compatible with the traditional "--get-color" option, unlike the latter, its output is not an incomplete line that lack the LF at the end.
That makes it consistent with output of other types like "git config --type=bool".

Document it, as it sometimes surprises unsuspecting users.

This now reads:

--type=color [--default=<default>] is preferred over --get-color (but note that --get-color will omit the trailing newline printed by --type=color).

---

You can see git config --type=bool used with Git 2.26 (Q1 2020) to replace "git config --bool" calls in sample templates.

See commit 81e3db4 (19 Jan 2020) by Lucius Hu (lebensterben).
^{(Merged by Junio C Hamano -- gitster -- in commit 7050624, 30 Jan 2020)}

templates: fix deprecated type option --bool

^{Signed-off-by: Lucius Hu}

The --bool option to git-config is marked as historical, and users are recommended to use --type=bool instead.
This commit replaces all occurrences of --bool in the templates.

Also note that, no other deprecated type options are found, including --int, --bool-or-int, --path, or --expiry-date.