En un repositorio de código Git, quiero enumerar todas las confirmaciones que contienen una determinada palabra. probé esto

git log -p | grep --context=4 "word"

pero no necesariamente me devuelve el nombre del archivo (a menos que esté a menos de cinco líneas de la palabra que busqué. También intenté

git grep "word"

pero solo me da archivos actuales y no la historia.

¿Cómo busco en todo el historial para poder seguir los cambios en una palabra en particular? Tengo la intención de buscar en mi base de código apariciones de palabras para rastrear cambios (buscar en el historial de archivos).

Si desea encontrar todas las confirmaciones en las que mensaje de compromiso contiene una palabra dada, use

$ git log --grep=word

Si desea encontrar todas las confirmaciones donde se agregó o eliminó “palabra” en el contenido del archivo (para ser más exactos: donde cambió el número de ocurrencias de “palabra”), es decir, buscar el confirmar contenidouse la llamada búsqueda ‘pickaxe’ con

$ git log -Sword

En Git moderno también hay

$ git log -Gword

buscar diferencias cuya línea agregada o eliminada coincide con “palabra” (también confirmar contenidos).

Algunas cosas a tener en cuenta:

• -G por defecto acepta una expresión regular, mientras que -S acepta una cadena, pero se puede modificar para aceptar expresiones regulares usando el --pickaxe-regex.
• -S encuentra confirmaciones donde cambió el número de ocurrencias de “palabra”, mientras que -G encuentra confirmaciones donde aparece “palabra” en la diferencia.
• Esto significa que -S<regex> --pickaxe-regex y -G<regex> no hagas exactamente lo mismo.

El git diff documentación tiene una buena explicación de la diferencia:

Para ilustrar la diferencia entre -S<regex> --pickaxe-regex y -G<regex>considere una confirmación con la siguiente diferencia en el mismo archivo:

+    return frotz(nitfol, two->ptr, 1, 0);
...
-    hit = frotz(nitfol, mf2.ptr, 1, 0);

Mientras git log -G"frotz\(nitfol" mostrará este compromiso, git log -S"frotz\(nitfol" --pickaxe-regex no lo hará (porque el número de ocurrencias de esa cadena no cambió).

Esto mostrará las confirmaciones que contienen los términos de búsqueda, pero si desea ver los cambios reales en esas confirmaciones, puede usar --patch:

$ git log -G"searchTerm" --patch

Esto puede entonces ser canalizado a grep para aislar la salida solo para mostrar líneas de confirmación de diferencia con ese término de búsqueda. Un caso de uso común es mostrar líneas de diferencias con ese término de búsqueda en confirmaciones desde e incluyendo una confirmación determinada: 3b5ab0f2a1 en este ejemplo – así:

$ git log 3b5ab0f2a1^.. -G"searchTerm" --patch | grep searchTerm

git logEl pico de encontrará confirmaciones con cambios que incluyen “palabra” con git log -Sword

Después de mucha experimentación, puedo recomendar lo siguiente, que muestra confirmaciones que introducen o eliminan líneas que contienen una expresión regular dada, y muestra los cambios de texto en cada una, con colores que muestran las palabras agregadas y eliminadas.

git log --pickaxe-regex -p --color-words -S "<regexp to search for>"

Sin embargo, tarda un poco en ejecutarse… 😉

Una forma/sintaxis más para hacerlo es: git log -S "word"

Así puedes buscar por ejemplo git log -S "with whitespaces and stuff @/#ü !"

Puedes probar el siguiente comando:

git log --patch --color=always | less +/searching_string

o usando grep de la siguiente manera:

git rev-list --all | GIT_PAGER=cat xargs git grep 'search_string'

Ejecute este comando en el directorio principal donde le gustaría buscar.

Para usar un conector booleano en una expresión regular:

git log --grep '[0-9]*\|[a-z]*'

Esta expresión regular busca la expresión regular [0-9]* o [a-z]* en mensajes de confirmación.

Esto es útil en combinación con BFG (Rama de filtro de Git: no debe confundirse con git-filter-branch) y git-filter-repo. Simplemente obtiene las rutas de los archivos para que pueda ingresarlos en una de las dos herramientas que acabo de mencionar.

A. Rutas relativas, únicas, ordenadas:

# Get all unique filepaths of files matching 'password'
# Source: https://stackoverflow.com/a/69714869/10830091
git rev-list --all | (
    while read revision; do
        git grep -F --files-with-matches 'password' $revision | cat | sed "s/[^:]*://"
    done
) | sort | uniq

B. Nombres de archivo únicos, ordenados (no rutas):

# Get all unique filenames matching 'password'
# Source: https://stackoverflow.com/a/69714869/10830091
git rev-list --all | (
    while read revision; do
        git grep -F --files-with-matches 'password' $revision | cat | sed "s/[^:]*://"
    done
) | xargs basename | sort | uniq

Este segundo comando es útil para BFG, porque solo acepta nombres de archivo y no rutas relativas al repositorio/absolutas del sistema.

Ahí tienes Disfrute usando estos fragmentos de Bash por tanta agonía como me causaron a mí. Odio a Bash, entonces, ¿por qué sigo usándolo?

Disección

Obtener solo nombres de archivo/rutas

Cualquiera de las siguientes opciones significa lo mismo (documentación de git-rep):

• -l
• --files-with-matches
• --name-only

En lugar de mostrar todas las líneas coincidentes, muestre solo los nombres de los archivos que contienen Blockquote

¿Es su patrón: A. Regex vs B. Fixed String?

Como para -Fbueno, solo significa usar una cadena fija en lugar de una expresión regular para la interpretación de patrones. Una fuente.

Otra nota útil que pertenece aquí: puede agregar -i o --ignore-case ser mayúsculas y minúsculas.

Deshazte de ese estúpido hash de confirmación principal

sed "s/[^:]*://"

Fuente.

¡Consígueles caminos únicos!

| sort | uniq

¿Quién quiere caminos duplicados? ¡Tú no, yo no! ¡Oh, mira, también están ordenados! Disfrutar.

Fuente: yo. He usado esto desde que tengo memoria. (man sort y man uniq)

¿Qué pasa con los nombres de archivo sin rutas?

xargs basename

Tu pensarias | basename funcionaría, pero no. No acepta entrada entrada estándar, pero como argumentos de línea de comando. Aquí está una explicación para eso. ¡Imagínate! basename básicamente devuelve el nombre de archivo principal sin su ruta principal. man basename.

Para el método A., quiero rutas absolutas, no relativas.

Claro, solo dale una palmada realpath al final. Al igual que:

) | sort | uniq | xargs realpath

Por supuesto que tienes que usar xargs porque realpath no utiliza la entrada estándar para la entrada. Utiliza argumentos de línea de comandos. Al igual que dirname.

inspiraciones

• Echa un vistazo a esta increíble respuesta alternativa.
• Buscar en todo el historial de Git una cadena
• Nombres de archivo solo usando Git grep