Comment colorer la console Git?

Comme indiqué par @VonC , color.ui défaut l’ auto depuis git 1.8.4. Pas une sortie trop tôt;)

De la question Stackexchange d’Unix & Linux Comment colorier la sortie de git? et la réponse de @Evgeny :

 git config --global color.ui auto 

color.ui est une méta-configuration qui comprend toutes les différentes color.* Configurations disponibles avec les commandes git . Ceci est expliqué en détail dans git help config .

Donc, en gros, c’est plus facile et plus sûr que de définir séparément les différents parameters de color.* .

Explication détaillée de la documentation de git config :

color.ui : cette variable détermine la valeur par défaut des variables telles que color.diff et color.grep qui contrôlent l’utilisation de la couleur par famille de commandes. Son étendue se développera à mesure que d’autres commandes apprendront la configuration pour définir une option par défaut pour l’option --color . Réglez-le sur always si vous souhaitez que toutes les sorties ne soient pas destinées à la consommation de la machine, à true ou à auto si vous souhaitez que les couleurs soient écrites sur le terminal, ou false ou never si vous préférez ne pas utiliser les couleurs sauf si explicitement avec une autre configuration ou l’option --color .

Par exemple, voir http://www.arthurkoziel.com/2008/05/02/git-configuration/

La partie intéressante est

Sortie colorisée:

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

Ajoutez à votre fichier .gitconfig le code suivant:

  [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 

Git colore automatiquement la plupart de ses sorties si vous le lui demandez. Vous pouvez être très précis sur ce que vous voulez colorer et comment; mais pour activer toutes les couleurs de terminal par défaut, définissez color.ui sur true:

 git config --global color.ui true 

Dans Ubuntu ou toute autre plate-forme (oui, Windows aussi!); à partir de git1.8.4 , qui a été publié le 23/08/2013 , vous ne devrez rien faire :

De nombreux didacticiels enseignent aux utilisateurs de définir “color.ui” sur “auto” comme première chose après avoir défini ” user.name/email ” pour vous présenter à Git. Maintenant, la variable par défaut est ” auto “.

Donc, vous verrez les couleurs par défaut.

Dans votre fichier ~/.gitconfig , ajoutez simplement ceci:

 [color] ui = auto 

Il prend en charge toutes vos commandes git.

Une autre méthode consiste à éditer le .gitconfig (en créer un s’il n’existe pas), par exemple:

 vim ~/.gitconfig 

puis ajoutez:

 [color] diff = auto status = auto branch = auto 

GIT utilise une sortie colorée par défaut mais sur certains systèmes comme CentOS, il n’est pas activé. Vous pouvez l’activer comme ça

 git config --global color.ui true git config --global color.ui false git config --global color.ui auto 

Vous pouvez choisir votre commande requirejse à partir d’ici.

Ici, –global est facultatif pour appliquer une action pour chaque référentiel de votre système. Si vous souhaitez appliquer la coloration pour le référentiel actuel uniquement, vous pouvez faire quelque chose comme ça –

  git config color.ui true 

Avec Git 2.18, vous avez plus de contrôle sur la manière dont vous souhaitez spécifier les couleurs dans la console.
La commande ” git config ” utilise des options distinctes, par exemple ” --int “, ” --bool “, etc. pour spécifier quel type l’appelant souhaite interpréter la valeur .

Une nouvelle --type= ” --type= ” a été introduite, ce qui la rend plus propre à définir de nouveaux types.

Voir commit fb0dc3b (18 avril 2018), et commettre 0a8950b (09 avril 2018) par Taylor Blau ( ttaylorr ) .
^{(Fusionné par Junio ​​C Hamano – gitster – dans commit e3e042b , 8 mai 2018)}

builtin/config.c : support --type= comme alias préféré pour --

git config a longtemps permis aux appelants de fournir un «spécificateur de type», qui indique à git config de (1) s’assurer que les valeurs entrantes peuvent être interprétées comme ce type et (2) que les valeurs sortantes sont canonisées sous ce type.

Dans une autre série, nous proposons d’étendre cette fonctionnalité avec --type=color et --default pour remplacer --get-color .

Cependant, nous utilisons traditionnellement --color pour signifier “coloriser cette sortie”, au lieu de “cette valeur doit être traitée comme une couleur”.

Actuellement, git config ne supporte pas ce type de colorisation, mais il faut éviter de squatter cette option trop tôt, afin que git config puisse supporter --color (au sens traditionnel) à l’avenir, si cela est souhaité.

Dans ce patch, nous --type= en plus de --int , --bool , etc.
Cela permet au patch susmentionné de prendre en charge l’interrogation d’une valeur de couleur par défaut via --type=color --default=... , sans gaspiller --color .

Nous conservons le comportement historique consistant à se plaindre lorsque plusieurs indicateurs de -- hérité -- sont donnés, ainsi qu’à étendre cela aux conflits de type nouveau – type --type= . --int --type=int (et sa paire commutative) ne se plaint pas, mais --bool --type=int (et sa paire commutative) le fait.

Donc, avant d’avoir --bool et --int , maintenant ( documentation ):

 --type  

‘ git config ‘ assurera que toute entrée ou sortie est valide sous la ou les contraintes de type données, et canonisera les valeurs sortantes dans la forme canonique de .

Les valides incluent:

• ‘ bool ‘: canaliser les valeurs soit ” true ” soit ” false “.
• ‘ int ‘: canaliser les valeurs en nombres décimaux simples. Un suffixe facultatif de « k », « m » ou « g » entraînera la multiplication de la valeur par 1024, 1048576 ou 1073741824 lors de la saisie.
• ‘ bool-or-int ‘: canonicalize selon soit ‘ bool ‘ soit ‘ int ‘, comme décrit ci-dessus.
• ‘ path ‘: canonicalize en ajoutant un ~ à la valeur de $HOME et ~user au répertoire de base pour l’utilisateur spécifié. Ce spécificateur n’a aucun effet lors de la définition de la valeur (mais vous pouvez utiliser git config section.variable ~/ depuis la ligne de commande pour permettre à votre shell d’effectuer l’extension).
• ‘ expiry-date ‘: canonicalize en convertissant d’une chaîne de dates fixe ou relative en un horodatage. Ce spécificateur n’a aucun effet lors de la définition de la valeur.

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