Color en git-log


106

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"

Respuestas:


91

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

60

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 .


3
¿No hay forma de usar --decorate y --pretty = "... stuff"?
NorthIsUp

8
@NorthlsUp: --decorate parece tener su propia implementación y configuración, mientras que --prettyofrece la misma información a través de %dun bloque, lo que significa que no puede tener el mismo nivel de configuración de color de grano fino con el --prettyque tiene --decorate.
VonC

La única diferencia que veo cuando agrego "--decorate" después de "git log" es que los repositorios comienzan con "refs / heads / ..." o "refs / remotes ...". Los colores se muestran de cualquier manera. ¿Alguna idea de lo que puede ocasionar esto? La razón por la que pregunto es que mi .gitconfig no muestra propiedades de color. Me pregunto dónde puedo encontrar mi propiedad "color.decorate". No lo veo en mi archivo .gitconfig.
J Woodchuck

@JWoodchuck Intente git config --show-origin -l: verá todas sus configuraciones. A continuación, puede grep para "color".
VonC

Sí, no aparece nada cuando busco el color, lo que hace que los ajustes se muestren tan misteriosos.
J Woodchuck

9

Ponlos entre paréntesis:

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

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


1
no del todo, %dson todas las ramas, por lo que podría verse (HEAD, master), en este caso, la cabeza debe ser azul y el maestro debe ser verde (creo que esos son los colores predeterminados). donde %C(yellow)%d%Cresetlo haría todo del mismo color.
NorthIsUp

2
Oh, colorear las decoraciones individuales. Creo que es imposible. El código para representar las entradas del registro se implementa básicamente dos veces.
Josh Lee

1
Lástima que esto no sea posible ... Me encantaría hacerlogit log --decorate --oneline --date=...
mgalgs

8

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.


3
log.decorate=fullhace que los nombres de las referencias se impriman con sus prefijos ( refs/heads/, etc.); Encuentro log.decorate=shortmás útil.
Musiphil

1
Configuración muy útil, aunque también prefiero en shortlugar defull
Thomas Levesque

4

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
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.