Color en git-log

Cuando ejecute git log --decorate --pretty=onelinela salida tendrá entradas como (HEAD, refs/published/master, master)con coloración.

También tengo lo siguiente en mi gitconfig:

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

¿Cómo replicas esos colores cuando haces un formato personalizado como el siguiente?

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

A partir de git 1.8.3 (24 de mayo de 2013), puede usar %C(auto)para decorar %den la cadena de formato git log.

De las notas de la versión :

 * "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.)

El git log --decoratepondrá por defecto:

• la CABEZA en cian
• las ramas remotas en rojo
• la etiqueta en verde

y se puede cambiar a través de color.decorateconfig.

Pero el git log --formatno ofrecen una forma de mostrar específicamente el HEAD o los mandos a distancia o rama: los tres se visualizan a través %d, con un color posible.

Actualización de mayo de 2013, como se menciona más adelante por Elad Shahar (upvoted), Git 1.8.3 ofertas una opción más:

git log –formatahora tiene un %C(auto)token que le dice a Git que use color al resolver %d(decoración), %h(nombre corto del objeto de confirmación), etc. para la salida del terminal.

Esta publicación de blog de Atlassian comenta que esta función es parte de varias otras centradas en el formato ( git rebase, git count-objects) y los colores ( git branch -vv)

Esto se suma a lo anterior auto,resetde 1.8.2 , que deshabilita automáticamente los colores cuando la salida no se usa para un terminal1

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

Nota: git 2.4+ (Q2 2015) hará un mejor trabajo al restablecer el color alrededor de los nombres de las ramas.
Ver el compromiso 5ee8758 de Junio ​​C Hamano ( gitster) :

log --decorate: no filtrar el color de "compromiso" en el siguiente elemento

En " git log --decorate", verá el encabezado de confirmación como este:

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

donde " commit ... (" está pintado en color.diff.commit, " HEAD" en color.decorate.head, " ," en color.diff.commit, el nombre de la rama en color.decorate.branchy luego cierra " )" encolor.diff.commit .

Si quisiera pintar el HEAD y el nombre de la rama local en el mismo color que el texto del cuerpo (tal vez porque el cian y el verde son demasiado tenues en una terminal en blanco y negro para ser legibles), no querría tener que decir

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

porque no podría reutilizar la misma configuración en un terminal blanco sobre negro. Ingenuamente esperarías

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

trabajar, pero desafortunadamente no es así.
Pinta la cadena " HEAD" y el nombre de la rama del mismo color que el paréntesis de apertura o la coma entre los elementos decorativos.
Esto se debe a que el código se olvida de restablecer el color después de imprimir el "prefijo" en su propio color.

Tenga en cuenta que git 2.5 (Q2 2015) corrige un error:

Véase el compromiso 429ad20 de Junio ​​C Hamano ( gitster) , 13 de mayo de 2015
^{(combinado con Junio ​​C Hamano - gitster- en el compromiso fd70780 , 22 de mayo de 2015)}

log: no acorte los nombres de las decoraciones demasiado pronto

La log --decoratemejora " " en Git 2.4 que muestra la confirmación en la punta de la rama actual, por ejemplo, " HEAD -> master", no funcionó con --decorate = full.

Git 2.9.x + (Q3 2016) fijará otro error y el honor color=autode%C(auto)

Git 2.10.2 (octubre de 2016) corrige otros errores con la confirmación 82b83da (29 de septiembre de 2016) y la confirmación c99ad27 (17 de septiembre de 2016) de René Scharfe (``) .
^{(Combinado por Junio ​​C Hamano - gitster- en el compromiso 76796d4 , 28 de octubre de 2016)}

pretty: evite agregar reinicio %C(auto)si la salida está vacía

Emitimos una secuencia de escape para restablecer el color y el atributo para %C(auto)asegurarnos de que la coloración automática se muestre según lo previsto.
Deje de hacer eso si la salida strbuf está vacía , es decir, cuando %C(auto)aparece al principio de la cadena de formato, porque entonces no hay necesidad de reiniciar y guardamos algunos bytes en la salida.

pretty: vamos a %C(auto)restablecer todos los atributos

Restablecer colores y atributos sobre %C(auto)para permitir el control automático de pleno dominio de aquéllas; de lo contrario, los atributos como negrita o reverso podrían seguir vigentes desde %Cmarcadores de posición anteriores .

Ponlos entre paréntesis:

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

Así %C(yellow reverse)funcionaría.

La opción de configuración log.decoratepuede habilitar / deshabilitar las decoraciones predeterminadas en los registros.

git config --global log.decorate full

Una vez hecho esto, puedes usar color.decorate.*para jugar con los colores.

Algunos pueden querer usar esto: %C(colorname) Esto no necesita cambiar la configuración de color.

Ejemplo: colorear el nombre del autor en amarillo

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

Los colores ANSI regulares deberían funcionar https://en.wikipedia.org/wiki/ANSI_escape_code

• negro
• rojo
• verde
• amarillo
• azul
• magenta
• cian
• blanco