Couleur dans git-log


106

Lorsque vous exécutez git log --decorate --pretty=onelinela sortie aura des entrées comme (HEAD, refs/published/master, master)avec la coloration.

J'ai également ce qui suit dans mon gitconfig:

[color "branch"]
    current = yellow reverse
    local = yellow
    remote = green

Comment reproduisez-vous ces couleurs lorsque vous créez un format personnalisé comme celui-ci?

git log --decorate --stat --graph --pretty=format:"%d %Cgreen%h%Creset (%ar - %Cred%an%Creset), %s%n"

Réponses:


91

Depuis git 1.8.3 (24 mai 2013), vous pouvez utiliser %C(auto)pour décorer %ddans la chaîne de format de git log.

À partir des notes de version :

 * "git log --format" specifier learned %C(auto) token that tells Git
   to use color when interpolating %d (decoration), %h (short commit
   object name), etc. for terminal output.)

60

Le git log --decoratemettra par défaut:

  • la TETE en cyan
  • les branches éloignées en rouge
  • le tag en vert

et peut être modifié via color.decorateconfig.

Mais ils git log --formatn'offrent pas de moyen d'afficher spécifiquement la HEAD ou les télécommandes ou la branche: les trois sont affichés à travers %d, avec une couleur possible.


Mise à jour de mai 2013, comme mentionné ci-dessous par Elad Shahar (voté pour), git 1.8.3 offre une option supplémentaire:

git log –formatarbore maintenant un %C(auto)jeton qui indique à Git d'utiliser la couleur lors de la résolution %d(décoration), %h(nom d'objet de validation court), etc. pour la sortie du terminal.

Ce billet de blog Atlassian commente que cette fonctionnalité fait partie de plusieurs autres axées sur le format ( git rebase, git count-objects) et les couleurs ( git branch -vv)

Cela vient en plus du précédent auto,resetde 1.8.2 , qui désactive automatiquement les couleurs lorsque la sortie n'est pas utilisée pour un terminal1

%C(auto,blue)Hello%C(auto,reset)

Remarque: git 2.4+ (Q2 2015) fera un meilleur travail de réinitialisation de la couleur autour des noms de branche.
Voir commit 5ee8758 de Junio ​​C Hamano ( gitster) :

log --decorate: ne pas diffuser la couleur "commit" dans l'élément suivant

Dans " git log --decorate", vous verriez l'en-tête de validation comme ceci:

commit ... (HEAD, jc/decorate-leaky-separator-color)

où " commit ... (" est peint dans color.diff.commit, " HEAD" dans color.decorate.head, " ," dans color.diff.commit, le nom de la branche dans color.decorate.branchet puis se ferme " )" dans color.diff.commit.

Si vous vouliez peindre la tête et le nom de la branche locale dans la même couleur que le corps du texte (peut-être parce que le cyan et le vert sont trop pâles sur un terminal noir sur blanc pour être lisible), vous ne voudriez pas avoir à dire

[color "decorate"]
    head = black
    branch = black

parce que vous ne pourriez pas réutiliser la même configuration sur un terminal blanc sur noir. Vous attendriez naïvement

[color "decorate"]
    head = normal
branch = normal

travailler, mais malheureusement ce n’est pas le cas.
Il peint la chaîne " HEAD" et le nom de la branche dans la même couleur que la parenthèse ouvrante ou la virgule entre les éléments de décoration.
C'est parce que le code oublie de réinitialiser la couleur après avoir imprimé le "préfixe" dans sa propre couleur.


Notez que git 2.5 (Q2 2015) corrige un bogue:

Voir commit 429ad20 de Junio ​​C Hamano ( gitster) , 13 mai 2015
(fusionné par Junio ​​C Hamano - gitster- dans le commit fd70780 , 22 mai 2015)

log: ne raccourcissez pas les noms de décoration trop tôt

L' log --decorateamélioration " " dans Git 2.4 qui montre le commit à la pointe de la branche actuelle, par exemple " HEAD -> master", ne fonctionnait pas avec --decorate = full.


Git 2.9.x + (Q3 2016) va fixer un autre bug et l' honneur color=autopour%C(auto)


Git 2.10.2 (octobre 2016) corrige d'autres bogues avec le commit 82b83da (29 septembre 2016) et le commit c99ad27 (17 septembre 2016) par René Scharfe (``) .
(Fusionné par Junio ​​C Hamano - gitster- dans commit 76796d4 , 28 octobre 2016)

pretty: éviter d'ajouter une réinitialisation %C(auto)si la sortie est vide

Nous émettons une séquence d'échappement pour réinitialiser la couleur et l'attribut pour %C(auto)s'assurer que la coloration automatique est affichée comme prévu.
Arrêtez de faire cela si le strbuf de sortie est vide , c'est-à-dire quand %C(auto)apparaît au début de la chaîne de format, car alors il n'y a pas besoin de réinitialisation et nous économisons quelques octets dans la sortie.

pretty: laissez %C(auto)réinitialiser tous les attributs

Couleurs Réinitialiser et attributs sur %C(auto)pour activer le contrôle automatique complet sur eux; sinon, les attributs tels que gras ou inversé pourraient toujours être en vigueur à partir des %Cespaces réservés précédents .


3
n'y a-t-il aucun moyen d'utiliser --decorate et --pretty = "... stuff"?
NorthIsUp

8
@NorthlsUp: --decoratesemble avoir sa propre implémentation et configuration, tout en --prettyoffrant les mêmes informations %den un seul bloc, ce qui signifie que vous ne pouvez pas avoir le même niveau de configuration de couleur fine avec celui --prettyque vous avez avec --decorate.
VonC

La seule différence que je vois quand j'ajoute "--decorate" après "git log" est que les dépôts commencent par "refs / heads / ..." ou "refs / remotes ...". Les couleurs apparaissent dans les deux sens. Une idée de ce qui causerait cela? La raison pour laquelle je demande est que mon .gitconfig ne montre aucune propriété de couleur. Je me demande où je peux trouver ma propriété "color.decorate". Je ne le vois pas dans mon fichier .gitconfig.
J Woodchuck

@JWoodchuck Try git config --show-origin -l: vous verrez toutes vos configurations. Vous pouvez alors grep pour "couleur".
VonC

Oui, rien ne s'affiche lorsque je recherche la couleur, ce qui rend les paramètres si mystérieux.
J Woodchuck

9

Mettez-les entre parenthèses:

%C(...): color specification, as described in color.branch.* config option

Cela %C(yellow reverse)fonctionnerait donc.


1
pas tout à fait, %dtoutes les branches peuvent-elles ressembler (HEAD, master), dans ce cas, la tête doit être bleue et le maître doit être vert (je crois que ce sont les couleurs par défaut). où %C(yellow)%d%Cresetferait tout de la même couleur.
NorthIsUp

2
Oh, colorier les décorations individuelles. Je pense que c'est impossible. Le code pour rendre les entrées de journal est essentiellement implémenté deux fois.
Josh Lee

1
Dommage que ce ne soit pas possible ... git log --decorate --oneline --date=...
j'adorerais

8

L'option de configuration log.decoratepeut activer / désactiver les décorations par défaut dans les journaux.

git config --global log.decorate full

Une fois que cela est fait, vous pouvez utiliser color.decorate.*pour jouer avec les couleurs


3
log.decorate=fullprovoque l'impression des noms de référence avec leurs préfixes ( refs/heads/, etc.); Je trouve log.decorate=shortplus utile.
musiphil

1
Cadre très utile, même si je préfère aussi shortplutôt quefull
Thomas Levesque

4

Certains voudront peut-être utiliser ceci: %C(colorname) Cela n'a pas besoin de changer la configuration des couleurs.

Exemple: coloration du nom de l'auteur en jaune

--pretty=format:"%C(yellow)%an%Creset"

Les couleurs ANSI régulières devraient fonctionner https://en.wikipedia.org/wiki/ANSI_escape_code

  • noir
  • rouge
  • vert
  • Jaune
  • bleu
  • magenta
  • cyan
  • blanc
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.