De la couleur dans git log

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

J'ai aussi de la suite dans mon gitconfig:

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

Comment reproduire ces couleurs pour faire un format personnalisé comme suit?

git log --decorate --stat --graph --pretty=format:"%d %Cgreen%h%Creset (%ar - %Cred%an%Creset), %s%n"
InformationsquelleAutor NorthIsUp | 2011-05-04
  1. 81

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

    De la 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.)
    InformationsquelleAutor Elad Shahar
  2. 57

    La git log --decorate mettra par défaut:

    • la TÊTE cyan
    • les branches distantes en rouge
    • le tag vert

    et peut être modifié par le biais de color.decorate config.

    Mais la git log --format n'offre pas de moyen d'afficher précisément la HEAD ou télécommandes ou branche: tous les trois sont affichées par le biais de %d, avec une seule couleur possible.

    Mise à jour Mai 2013, comme mentionnés ci-dessous par Elad Shahar (upvoted), git 1.8.3 offre une option de plus:

    git log –format arbore désormais un %C(auto) jeton qui indique à Git pour l'utilisation de la couleur lors de la résolution de %d (décoration), %h (court commettre nom de l'objet), etc. pour la sortie du terminal.

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

    Cela vient en plus de la précédente auto reset de la 1.8.2, qui désactive automatiquement les couleurs lors de la sortie n'est pas utilisée pour une terminal1

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

    Remarque: git 2.4+ (Q2 2015) permettra de faire un meilleur travail de la réinitialisation de couleur autour de noms de branche.

    Voir s'engager 5ee8758 par Junio C Hamano (gitster):

    log --decorate: ne coule pas "s'engager" la couleur dans l'élément suivant

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

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

    où "commit ... (" est peint en color.diff.commit, "HEAD" dans color.decorate.head, ", " dans color.diff.commit, le nom de la branche dans
    color.decorate.branch et puis de la fermeture de ")" dans color.diff.commit.

    Si vous voulais peindre la TÊTE et le nom de la branche locale de la même couleur que le corps du texte (peut-être parce que le cyan et le vert sont trop faibles noir-sur-blanc terminal pour être lisible), vous ne voulez pas avoir à dire

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

    parce que vous ne seriez pas en mesure de réutiliser la même configuration sur un blanc-sur-noir de terminal. Vous naïvement attendre 

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

    de travail, mais malheureusement il ne fonctionne pas.

    Il peint la chaîne "HEAD" et le nom de la branche de la même couleur que l'ouverture de la parenthèse ou une virgule entre les éléments de décoration.

    C'est parce que le code oublie pour réinitialiser la couleur après l'impression, le "préfixe" dans sa propre couleur.

    Noter que git 2.5 (T2 2015) correction d'un bug:

    Voir s'engager 429ad20 par Junio C Hamano (gitster), 13 Mai 2015.

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager fd70780, 22 Mai 2015)

    log: ne pas raccourcir la décoration de noms trop tôt

    La "log --decorate" amélioration dans Git 2.4 montre que les commettre, à l'extrémité de la branche courante, par exemple "HEAD -> master", ne fonctionne pas avec --décorer=full.

    Git 2.9.x+ (Q3 2016) fixera un autre bug, et l'honneur de color=auto par %C(auto)

    Git 2.10.2 (Oct. 2016) résout d'autres bugs avec s'engager 82b83da (29 septembre 2016), et s'engager c99ad27 le 17 septembre 2016) par René Scharfe (`).

    (Fusionnés par Junio C Hamano -- gitster -- dans s'engager 76796d4, le 28 octobre 2016)

    pretty: éviter l'ajout de réinitialisation pour %C(auto) si la sortie est vide

    Nous émettons une séquence d'échappement pour réinitialiser les couleurs et les attributs pour %C(auto) pour vous assurer une colorisation automatique s'affiche comme prévu.

    Arrêter de le faire si la sortie strbuf est vide, c'est à dire quand %C(auto) apparaît au début de la chaîne de format, car il n'est pas nécessaire pour une remise et nous économiser quelques octets dans la sortie.

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

    Réinitialiser les couleurs et attributs sur %C(auto) pour activer le mode full automatique
    le contrôle sur eux; sinon des attributs comme le gras ou l'inverse pourrait
    toujours être en vigueur à partir de la précédente %C espaces réservés    .

    • il n'y a pas moyen d'utiliser --décorer et --pretty="...des trucs"?
    • semble avoir sa propre mise en œuvre et la configuration, tout en --pretty offre les mêmes informations par le biais %d comme un bloc, ce qui signifie que vous ne peut pas avoir la même fine au niveau de la configuration de la couleur avec --pretty que vous avez avec --decorate.
    • La seule différence que je vois quand je ajouter "--décorer" après "git log" est le repos de commencer avec "refs/heads/..." ou "refs/remotes...". Les couleurs montrent la voie. Toute idée de ce que serait à l'origine? La raison pour laquelle je demande est mon .gitconfig ne pas afficher toutes les propriétés de la couleur. Je me demandais où je peux trouver ma couleur".décorer de la propriété". Je ne le vois pas dans mon .gitconfig fichier.
    • Essayez git config --show-origin -l: vous verrez tous vos configs. Vous pouvez ensuite grep pour "couleur".
    • Yep, rien ne s'affiche lorsque je grep pour la couleur, ce qui rend où les paramètres sont en train d'apparaître si mystérieux.
    • Qui pourrait être à cause de la couleur.l'interface utilisateur est défini sur true ou auto depuis Git 1.8.4: git-scm.com/docs/git-config#git-config-colorui
    • Semble plausible, compte tenu que c'est apparemment à partir d'un il ya longtemps et je suis sur 2.16.2. Merci!

    InformationsquelleAutor VonC
  3. 9

    Parenthesize eux:

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

    Donc %C(yellow reverse) serait de travailler.

    • pas tout à fait, %d est toutes les branches de sorte qu'il pourrait ressembler à (HEAD, master), dans ce cas, la tête doit être le bleu et le maître doit être vert (je crois que ceux sont les couleurs par défaut). où %C(yellow)%d%Creset ferait-il de la même couleur.
    • Oh, la coloration de l'décorations. Je pense que c'est impossible. Le code de rendre les entrées de journal est essentiellement mis en œuvre deux fois.
    • Dommage que ce n'est pas possible... j'aimerais faire git log --decorate --oneline --date=...
    InformationsquelleAutor Josh Lee
  4. 7

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

    git config --global log.decorate full

    Une fois que c'est fait, vous pouvez utiliser color.decorate.* de jouer avec les couleurs

    • log.decorate=full provoque la ref noms à être imprimés avec leurs préfixes (refs/heads/, etc.); Je trouve log.decorate=short plus utile.
    • Paramètre très utile, bien que je préfère aussi short plutôt que full
    • pouvez-vous où cela est documenté?
    InformationsquelleAutor Henrik Gustafsson
  5. 1

    Certains voudront peut-être utiliser ce : %C(colorname)
    Ce n'est pas nécessaire de changer la couleur de config.

    Exemple : Coloriage le nom de l'auteur en jaune

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

    Régulier couleurs ANSI devrait fonctionner https://en.wikipedia.org/wiki/ANSI_escape_code

    • noir
    • rouge
    • vert
    • jaune
    • bleu
    • magenta
    • cyan
    • blanc
    InformationsquelleAutor NullPointerWizard