git-blame: en línea en la nube

PROGRAMA:

NOMBRE

git-blame: muestra qué revisión y autor modificó por última vez cada línea de un archivo

SINOPSIS

git culpa [-c] [-b] [-l] [--raíz] [-t] [-f] [-n] [-s] [-e] [-p] [-w] [--incremental]
[-L ] [-S ] [-M] [-C] [-C] [-C] [--desde = ]
[--abbrev = ] [ | --contenido | --marcha atrás ] [-]

DESCRIPCIÓN

Anota cada línea en el archivo dado con información de la revisión que se
modificó la línea. Opcionalmente, comience a anotar desde la revisión dada.

Cuando se especifica una o más veces, -L restringe la anotación a las líneas solicitadas.

El origen de las líneas se sigue automáticamente a través de cambios de nombre de archivos completos (actualmente hay
no hay opción para desactivar el cambio de nombre). Para seguir líneas movidas de un archivo a
otro, o para seguir las líneas que se copiaron y pegaron de otro archivo, etc., consulte el
Opciones -C y -M.

El informe no le dice nada sobre las líneas que se han eliminado o reemplazado; usted
necesita utilizar una herramienta como git diff o la interfaz "pico" que se menciona brevemente en el
párrafo siguiente.

Además de admitir la anotación de archivos, Git también admite la búsqueda en el historial de desarrollo
para cuando se produjo un fragmento de código en un cambio. Esto hace posible rastrear cuando un código
El fragmento se agregó a un archivo, se movió o se copió entre archivos y, finalmente, se eliminó o
reemplazado. Funciona buscando una cadena de texto en el archivo diff. Un pequeño ejemplo del
interfaz de pico que busca blame_usage:

$ git log --pretty = oneline -S'blame_usage '
5040f17eba15504bad66b14a645bddd9b015ebb7 blame -S <ancestry-file>
ea4c7f9bf69e781dd0cd88d2bccb2bf5cc15c9a7 git-blame: Make the output

CAMPUS

-b
Muestre SHA-1 en blanco para confirmaciones de límites. Esto también se puede controlar a través del
Opción de configuración blame.blankboundary.

--raíz
No trate las confirmaciones raíz como límites. Esto también se puede controlar a través del
Opción de configuración blame.showRoot.

--mostrar estadísticas
Incluya estadísticas adicionales al final de la salida de culpa.

-L , , -L:
Anote solo el rango de línea dado. Puede especificarse varias veces. Superposición
Se permiten rangos.

y son opcionales. "-L "O" -L , "Abarca desde para
fin del documento. "-L, ”Abarca desde el inicio del archivo hasta .

y puede tomar una de estas formas:

· número

Si o es un número, especifica un número de línea absoluto (las líneas cuentan
desde 1).

· / Regex /

Este formulario utilizará la primera línea que coincida con la expresión regular POSIX dada. Si es un
regex, buscará desde el final del rango -L anterior, si lo hay, de lo contrario
desde el inicio del archivo. Si es "^ / regex /", buscará desde el principio de
expediente. Si es una expresión regular, buscará comenzando en la línea dada por .

· + Desplazamiento o -desplazamiento

Esto solo es válido para y especificará un número de líneas antes o después
la línea dada por .

Si ": "Se da en lugar de y , es una expresión regular
que denota el rango desde la primera línea de nombre de función que coincide , hasta el
siguiente línea funcname. “: "Busca desde el final del rango -L anterior, si
any, de lo contrario desde el inicio del archivo. “^: ”Busca desde el inicio del archivo.

-l
Mostrar rev. Larga (predeterminado: desactivado).

-t
Mostrar marca de tiempo sin procesar (predeterminado: desactivado).

-S
Use revisiones de revs-file en lugar de llamar git-rev-lista(1).

--contrarrestar
Camine la historia hacia adelante en lugar de hacia atrás. En lugar de mostrar la revisión en la que un
apareció una línea, esto muestra la última revisión en la que ha existido una línea. Esto requiere
un rango de revisión como START..END donde la ruta de la culpa existe en START.

-p, - porcelana
Mostrar en un formato diseñado para el consumo de la máquina.

- línea de porcelana
Muestre el formato de porcelana, pero envíe la información de confirmación para cada línea, no solo la
primera vez que se hace referencia a una confirmación. Implica: porcelana.

- incremental
Muestre el resultado de forma incremental en un formato diseñado para el consumo de la máquina.

--encoding =
Especifica la codificación utilizada para generar nombres de autores y confirmar resúmenes. Poniéndolo en
ninguno hace que la culpa produzca datos no convertidos. Para obtener más información, consulte la discusión.
sobre la codificación en el registro de git(1) página de manual.

--contenido
Cuando no se especifica, el comando anota los cambios comenzando hacia atrás desde
la copia del árbol de trabajo. Esta bandera hace que el comando finja como si el árbol de trabajo copiara
tiene el contenido del archivo nombrado (especificar - para que el comando se lea desde el
entrada estándar).

--fecha
Especifica el formato utilizado para generar fechas. Si no se proporciona --date, el valor de la
Se utiliza la variable de configuración blame.date. Si la variable de configuración blame.date tampoco está configurada,
se utiliza el formato iso. Para conocer los valores admitidos, consulte la discusión de la opción --date
at registro de git(1).

-M | |
Detecta líneas movidas o copiadas dentro de un archivo. Cuando una confirmación mueve o copia un bloque de
líneas (por ejemplo, el archivo original tiene A y luego B, y la confirmación lo cambia a B y
luego A), el tradicional culpa El algoritmo nota solo la mitad del movimiento y
Por lo general, culpa a los padres de las líneas que se movieron hacia arriba (es decir, B) y asigna la culpa
a las líneas que se movieron hacia abajo (es decir, A) a la confirmación secundaria. Con esta opción, ambos
los grupos de líneas se atribuyen al padre mediante la ejecución de pasadas adicionales de inspección.

es opcional pero es el límite inferior del número de caracteres alfanuméricos
que Git debe detectar como movimiento / copia dentro de un archivo para asociar esas líneas
con el compromiso de los padres. El valor predeterminado es 20.

-C | |
Además de -M, detecta líneas movidas o copiadas de otros archivos que fueron modificados en
el mismo compromiso. Esto es útil cuando reorganiza su programa y mueve el código
a través de archivos. Cuando esta opción se da dos veces, el comando busca adicionalmente
copias de otros archivos en la confirmación que crea el archivo. Cuando se da esta opción
tres veces, el comando busca además copias de otros archivos en cualquier confirmación.

es opcional pero es el límite inferior del número de caracteres alfanuméricos
que Git debe detectar como movimiento / copia entre archivos para asociar esas líneas
con el compromiso de los padres. Y el valor predeterminado es 40. Si hay más de un -C
opciones dadas, el El argumento de la última -C tendrá efecto.

-h
Mostrar mensaje de ayuda.

-c
Utilice el mismo modo de salida que git-anotar(1) (predeterminado: desactivado).

--puntuación-depuración
Incluir información de depuración relacionada con el movimiento de líneas entre archivos (ver -C)
y líneas movidas dentro de un archivo (ver -M). El primer número en la lista es la puntuación. Este es
el número de caracteres alfanuméricos detectados que se han movido entre o dentro
archivos. Esto debe estar por encima de un cierto umbral para git culpa para considerar esas líneas de
código para haber sido movido.

-f, --mostrar-nombre
Muestra el nombre del archivo en la confirmación original. Por defecto, el nombre del archivo se muestra si hay
cualquier línea que provenga de un archivo con un nombre diferente, debido a la detección de cambio de nombre.

-n, --mostrar-número
Muestra el número de línea en la confirmación original (predeterminado: desactivado).

-s
Suprima el nombre del autor y la marca de tiempo de la salida.

-e, --show-correo electrónico
Muestre el correo electrónico del autor en lugar del nombre del autor (predeterminado: desactivado). Esto también puede ser
controlado a través de la opción de configuración blame.showEmail.

-w
Ignore los espacios en blanco al comparar la versión de los padres y la del niño para encontrar dónde
vinieron las líneas.

--abbrev =
En lugar de utilizar los dígitos hexadecimales predeterminados de 7 + 1 como nombre abreviado del objeto,
usar +1 dígitos. Tenga en cuenta que se utiliza 1 columna para un símbolo de intercalación para marcar el compromiso de límite.

EL REINO UNIDO PORCELANA FORMATO

En este formato, cada línea sale después de un encabezado; el encabezado como mínimo tiene el
primera línea que tiene:

· SHA-40 de 1 bytes de la confirmación a la que se atribuye la línea;

· El número de línea de la línea en el archivo original;

· El número de línea de la línea en el archivo final;

· En una línea que comienza un grupo de líneas de una confirmación diferente a la anterior,
el número de líneas de este grupo. En las líneas siguientes, este campo está ausente.

Esta línea de encabezado va seguida de la siguiente información al menos una vez por cada confirmación:

· El nombre del autor ("autor"), correo electrónico ("autor-correo"), hora ("autor-hora") y zona horaria
("autor-tz"); de manera similar para el committer.

· El nombre del archivo en la confirmación al que se atribuye la línea.

· La primera línea del mensaje de registro de confirmación ("resumen").

El contenido de la línea real se emite después del encabezado anterior, precedido por una TAB. Esta
es permitir agregar más elementos de encabezado más adelante.

El formato de porcelana generalmente suprime la información de compromiso que ya se ha visto.
Por ejemplo, se mostrarán dos líneas que se atribuyen a la misma confirmación, pero la
los detalles de esa confirmación se mostrarán solo una vez. Esto es más eficiente, pero puede requerir
El lector mantendrá más estado. La opción --line-porcelain se puede utilizar para producir
confirmar información para cada línea, lo que permite un uso más simple (pero menos eficiente) como:

# contar el número de líneas atribuidas a cada autor
git blame - lima de porcelana en línea |
sed -n 's / ^ autor // p' |
ordenar | uniq -c | sort -rn

ESPECIFICANDO RANGOS

Diferente a la git culpa y git anotar en versiones anteriores de git, el alcance de la anotación
se puede limitar tanto a rangos de línea como a rangos de revisión. La opción -L, que limita
anotación a un rango de líneas, se puede especificar varias veces.

Cuando esté interesado en encontrar el origen de las líneas 40-60 para el archivo foo, puede usar
la opción -L así (significan lo mismo: ambos piden 21 líneas que comienzan en la línea
40):

git culpe -L 40,60 foo
git culpar -L 40, + 21 foo

También puede usar una expresión regular para especificar el rango de línea:

git blame -L '/ ^ sub hello {/, / ^} $ /' foo

que limita la anotación al cuerpo de la subrutina de saludo.

Cuando no esté interesado en cambios anteriores a la versión v2.6.18 o cambios anteriores a 3
semanas, puede usar especificadores de rango de revisión similares a git lista de revoluciones:

git blame v2.6.18 .. - foo
git blame --since = 3.weeks - foo

Cuando se utilizan especificadores de rango de revisión para limitar la anotación, las líneas que no
cambiado desde el límite del rango (ya sea la confirmación v2.6.18 o la confirmación más reciente que
tiene más de 3 semanas en el ejemplo anterior) son culpados por esa confirmación de límite de rango.

Una forma particularmente útil es ver si un archivo agregado tiene líneas creadas por copiar y pegar
de archivos existentes. A veces, esto indica que el desarrollador estaba siendo descuidado y no
no refactorizar el código correctamente. Primero puede encontrar la confirmación que introdujo el archivo
con:

git log --diff-filter = A --pretty = short - foo

y luego anote el cambio entre el compromiso y sus padres, usando commit ^! notación:

git culpar -C -C -f $ commit ^! - foo

INCREMENTALES SALIDA

Cuando se llama con la opción --incremental, el comando genera el resultado a medida que se construye. los
la salida generalmente hablará sobre las líneas tocadas por confirmaciones más recientes primero (es decir, el
las líneas se anotarán fuera de orden) y está destinado a ser utilizado por visores interactivos.

El formato de salida es similar al formato de porcelana, pero no contiene el formato real
líneas del archivo que se está anotando.

1. Cada entrada de culpa siempre comienza con una línea de:

<Sha40 hexadecimal de 1 bytes>

Los números de línea cuentan desde 1.

2. La primera vez que aparece una confirmación en la transmisión, tiene otra información
sobre él impreso con una etiqueta de una palabra al principio de cada línea que describe el
información adicional de confirmación (autor, correo electrónico, autor, fechas, resumen, etc.).

3. A diferencia del formato de porcelana, la información del nombre del archivo siempre se proporciona y termina
la entrada:

"nombre del archivo"

y, por lo tanto, es realmente bastante fácil de analizar para algún analizador orientado a líneas y palabras
(que debería ser bastante natural para la mayoría de los lenguajes de secuencias de comandos).

Note
Para las personas que realizan análisis: para hacerlo más sólido, simplemente ignore las líneas entre
el primero y el último (" "y" líneas de "nombre de archivo") donde no reconoce
las palabras de la etiqueta (o se preocupan por esa en particular) al comienzo de la
líneas de "información ampliada". De esa forma, si alguna vez se agrega información (como
la codificación de confirmación o el comentario de confirmación extendido), a un espectador culpable no le importará.

CARTOGRAFÍA AUTORES

Si el archivo .mailmap existe en el nivel superior del repositorio, o en la ubicación señalada
a por las opciones de configuración mailmap.file o mailmap.blob, se utiliza para mapear autor y
los nombres de los confirmadores y las direcciones de correo electrónico a los nombres reales canónicos y las direcciones de correo electrónico.

En la forma simple, cada línea del archivo consta del nombre canónico real de un
autor, espacios en blanco y una dirección de correo electrónico utilizada en la confirmación (delimitada por < y >) para asignar
al nombre. Por ejemplo:

Nombre correcto[email protected]>

Las formas más complejas son:

<[email protected]>[email protected]>

que permite que mailmap reemplace solo la parte de correo electrónico de una confirmación, y:

Nombre correcto[email protected]>[email protected]>

que permite que mailmap reemplace tanto el nombre como el correo electrónico de una confirmación que coincida con el
dirección de correo electrónico de confirmación especificada y:

Nombre correcto[email protected]> Nombre de compromiso[email protected]>

que permite que mailmap reemplace tanto el nombre como el correo electrónico de una confirmación que coincida con
nombre de confirmación y dirección de correo electrónico especificados.

Ejemplo 1: su historial contiene confirmaciones de dos autores, Jane y Joe, cuyos nombres aparecen
en el repositorio bajo varias formas:

Joe Desarrollador[email protected]>
Joe R. Desarrollador[email protected]>
fulano de tal[email protected]>
fulano de tal
Jane D.

Ahora suponga que Joe quiere que se use la inicial de su segundo nombre, y Jane prefiere su apellido
completamente enunciado. Un archivo .mailmap adecuado se vería así:

fulano de tal
Joe R. Desarrollador[email protected]>

Tenga en cuenta que no hay necesidad de una entrada para , porque el nombre real de
ese autor ya tiene razón.

Ejemplo 2: su repositorio contiene confirmaciones de los siguientes autores:

nick1[email protected]>
nick2[email protected]>
nick2[email protected]>
Papa Noel[email protected]>
claus[email protected]>
CTO[email protected]>

Entonces es posible que desee un archivo .mailmap que se parezca a:

<[email protected]>[email protected]>
Algún tipo[email protected]> nick1[email protected]>
Otro autor[email protected]> nick2[email protected]>
Otro autor[email protected]>[email protected]>
Papá Noel[email protected]>[email protected]>

Usa hash # para comentarios que están en su propia línea o después de la dirección de correo electrónico.

Use git-blame en línea usando los servicios de onworks.net