tener - ¿Hay alguna manera de personalizar la salida de Git Culk?
¿qué hace git log-oneline? (4)
Actualización de Git 2.18 (Q2 2018): " git blame " aprende a resaltar los metadatos no interesantes de la confirmación original en líneas que son iguales a la anterior, y también a pintar líneas en diferentes colores dependiendo de la edad de la confirmación.
Ver commit 0dc95a4 , commit 25d5f52 , commit cdc2d5f (24 de abril de 2018) por Stefan Beller ( stefanbeller ) .
(Fusionada por Junio C Hamano - gitster - in commit 3d24129 , 30 de mayo de 2018)
builtin/blame: añadir nuevo esquema de colorear configAgregue una opción de configuración que permita seleccionar la combinación de colores predeterminada para culpar. La línea de comando todavía tiene prioridad sobre la configuración.
git config ahora informa:
blame.coloring::Esto determina el esquema de coloración que se aplicará para culpar a la salida.
Puede ser ''repeatedLines'', ''highlightRecent'' o ''none'', que es el valor predeterminado.
builtin / blame: resaltar líneas recientemente modificadas
Elija un color diferente para las fechas e imite un ''enfriamiento de temperatura'' dependiendo de la edad.
Al igual que en el parche anterior, ofrece la opción de línea de comando ''
--color-by-age'' para habilitar este modo y la opción de configuración ''color.blame.highlightrecent'' para seleccionar colores.
La documentación ahora agrega:
color.blame.highlightRecentEsto se puede usar para colorear los metadatos de una línea de culpable según la antigüedad de la línea.
Esta configuración debe establecerse en una lista de ajustes de color y fecha separados por comas, comenzando y terminando con un color, las fechas deben establecerse de la más antigua a la más reciente.
Los metadatos se colorearán teniendo en cuenta los colores si la línea se introdujo antes de la marca de tiempo dada, sobrescribiendo los colores más antiguos con marca de tiempo.
En lugar de una marca de tiempo absoluta, las marcas de tiempo relativas también funcionan, por ejemplo, 2.weeks.ago es válido para abordar cualquier cosa que tenga más de 2 semanas.
El valor predeterminado es ''
blue,12 month ago,white,1 month ago,red'', que colorea todo lo que tiene más de un año de color azul, los cambios recientes entre un mes y un año se mantienen blancos y las líneas introducidas en el último mes están coloreadas rojo.
builtin/blame: atenuar líneas de metadatos poco interesantesCuando se usa
git-blame, muchas líneas contienen información redundante, por ejemplo, en cuentos que constan de múltiples líneas, se repiten los metadatos (nombre de confirmación, autor, fecha).
Es posible que un lector no esté interesado en ellos, por lo que ofrece una opción para colorear la información que se repite desde la línea anterior de manera diferente.
Tradicionalmente, usamos CYAN para líneas que son menos interesantes que otras (por ejemplo, encabezado de hunk), así que sigue con eso.La opción de línea de comando ''
--color-lines'' activará la coloración de líneas repetidas, y se proporciona la opción de configuración ''color.blame.colorLines'' para seleccionar el color.
Establecer la opción de configuración no implica que las líneas repetidas estén coloreadas.
Respuesta original 2010
Teniendo en cuenta que la interfaz web como Trac o Redmine integran los resultados de Git git blame , supongo que ya se ha realizado un análisis de este tipo.
Puedes ver en este Defecto de Redmine 3832 un ejemplo con este script ruby:
git log tiene una buena opción --format para especificar cómo debe formatearse la salida.
Pero la git blame no parece tener un equivalente, aunque la salida por defecto de la blame no es muy amigable para los humanos. Me gustaría ver mucho menos.
Por ejemplo, en lugar de:
5600cab7 js/sidebar/VehicleGrid.js (Rene Saarsoo 2009-10-08 18:55:24 +0000 127) if (x > y) {
b5f1040c js/map/monitoring/VehicleGrid.js (Mihkel Muhkel 2010-05-31 07:20:13 +0000 128) return x;
Me gustaría tener:
5600cab7 Rene Saarsoo (1 year ago) 127: if (x > y) {
b5f1040c Mihkel Muhkel (5 months ago) 128: return x;
Me imagino que podría escribir un script para analizar la salida de git blame --porcelain pero dada la horrenda salida por defecto de la blame , siento que alguien ya debe haber hecho algo al respecto.
¿Algunas ideas? ¿O algún consejo para implementar tal script?
Edición: Resuelto por escribir pequeño guión .
Para mí, la marca -s funciona, porque todo lo que necesito es el ID SHA1, después de lo cual busco la confirmación para obtener más detalles. Un guión definitivamente parece una exageración. ¿Es posible que la bandera -s no estuviera disponible hace un año?
Puede usar un formato de salida alternativo: git annotate o git blame -c .
Puede cambiar el formato de las fechas con la --date=<format> (o la variable de configuración blame.date ), donde <format> es una de relativa, local, predeterminada, iso, rfc, corta . Vea las páginas de manual de git-blame y git-log para más detalles.
Ya que git log proporciona muchas más opciones de personalización para la salida, puedes combinar git blame , awk , xargs y git log para lograr lo que deseas. P.ej
git --no-pager blame <filepath> -L1,+1 --porcelain | awk ''NR==1 {print $1}'' | xargs git --no-pager log -1 --pretty=format:"%h - (%cd) %s - %an" --date=relative
Esto produce algo como esto:
f8a66e80c - (5 months ago) Add gem: devise - elquimista
Básicamente, lo que git blame y awk hacen arriba es obtener un SHA de confirmación completo, y xargs pasa al git log como un argumento.