¿Cómo puedo "abusar" de la culpa (o alguna función más adecuada, y / o junto con los comandos de shell) para darme una estadística de cuántas líneas (de código) hay actualmente en el repositorio que se originan en cada committer?
Salida de ejemplo:
Committer 1: 8046 Lines
Committer 2: 4378 Lines
Respuestas:
Actualizar
He actualizado algunas cosas en el camino.
Por conveniencia, también puede poner esto en su propio comando:
almacena esto en algún lugar de tu camino o modifica tu camino y úsalo como
git authors '*/*.c' # look for all files recursively ending in .c
git authors '*/*.[ch]' # look for all files recursively ending in .c or .h
git authors 'Makefile' # just count lines of authors in the Makefile
Respuesta original
Si bien la respuesta aceptada hace el trabajo, es muy lenta.
Es casi instantáneo.
Para obtener una lista de los archivos actualmente rastreados, puede usar
Esta solución evita llamar
file
para determinar el tipo de archivo y utiliza grep para que coincida con la extensión deseada por razones de rendimiento. Si se deben incluir todos los archivos, simplemente elimine esto de la línea.si los archivos pueden contener espacios, que son malos para los shells, puede usar:
Dé una lista de archivos (a través de una tubería), uno puede usar xargs para llamar a un comando y distribuir los argumentos. Los comandos que permiten que se procesen varios archivos, obmiten el
-n1
. En este caso llamamosgit blame --line-porcelain
y para cada llamada usamos exactamente 1 argumento.Luego filtramos la salida para las ocurrencias de "autor", ordenamos la lista y contamos las líneas duplicadas por:
Nota
Otras respuestas en realidad filtran líneas que contienen solo espacios en blanco.
El comando anterior imprimirá autores de líneas que contengan al menos un carácter que no sea un espacio en blanco. También puede usar la coincidencia,
\w*[^\w#]
que también excluirá líneas donde el primer carácter que no sea un espacio en blanco no es un#
(comentario en muchos lenguajes de secuencias de comandos).fuente
echo "a\nb\nc"|xargs -n1 cmd
se expandirá acmd a; cmd b; cmd d
git ls-tree --name-only -r HEAD | grep -E '\.(cc|h|m|hpp|c)$' | xargs -n1 git blame --line-porcelain | grep "^author "|sort|uniq -c|sort -nr
Escribí una gema llamada git-fame que podría ser útil.
Instalación y uso:
$ gem install git_fame
$ cd /path/to/gitdir
$ git fame
Salida:
fuente
Explicación paso a paso:
Listar todos los archivos bajo control de versiones
Pode la lista solo a archivos de texto
Culpe a todos los archivos de texto, ignorando los cambios en los espacios en blanco
Saca los nombres de los autores
Ordene la lista de autores y haga que uniq cuente el número de líneas repetidas consecutivamente
Salida de ejemplo:
fuente
sed
versión diferente , la mía no entiende la-r
bandera y tiene problemas con la expresión regular (se queja de padres desequilibrados, incluso cuando elimino el excedente(
).sudo brew install gnu-sed
resolvió. ¡Funciona de maravilla!port install gsed
para usuarios de MacPorts.sudo brew install gnu-sed
(que funcionó) pero todavía recibo errores que sed no reconoce -r. :(git ls-tree -r HEAD|gsed -re 's/^.{53}//'|while read filename; do file "$filename"; done|grep -E ': .*text'|gsed -r -e 's/: .*//'|while read filename; do git blame -w "$filename"; done|gsed -r -e 's/.*\((.*)[0-9]{4}-[0-9]{2}-[0-9]{2} .*/\1/' -e 's/ +$//'|sort|uniq -c
git summary
proporcionado por el paquete git-extras es exactamente lo que necesita. Consulte la documentación en git-extras - git-summary :Da una salida que se ve así:
fuente
La solución de Erik fue increíble, pero tuve algunos problemas con los signos diacríticos (a pesar de que mis
LC_*
variables de entorno se configuraron aparentemente correctamente) y el ruido que se filtraba en las líneas de código que realmente tenían fechas. Mi sed-fu es pobre, así que terminé con este fragmento de frankenstein con rubí, pero me funciona perfectamente en más de 200,000 LOC, y clasifica los resultados:También tenga
gsed
en cuenta en lugar desed
porque esas son las instalaciones binarias homebrew, dejando el sistema intacto.fuente
git shortlog -sn
Esto mostrará una lista de confirmaciones por autor.
fuente
Aquí está el fragmento principal de la respuesta de @Alex que realmente realiza la operación de agregar las líneas de culpa. Lo he reducido para operar en un solo archivo en lugar de un conjunto de archivos.
Publico esto aquí porque vuelvo a esta respuesta a menudo y releo la publicación y vuelvo a digerir los ejemplos para extraer la parte que valoro que está gravando. Tampoco es lo suficientemente genérico para mi caso de uso; su alcance es para un proyecto completo de C.
Me gusta enumerar las estadísticas por archivo, logrado a través de un
for
iterador bash en lugar dexargs
porque encuentro que xargs es menos legible y difícil de usar / memorizar. Las ventajas / desventajas de xargs vs para deberían discutirse en otra parte.Aquí hay un fragmento práctico que mostrará resultados para cada archivo individualmente:
Y probé, ejecutar este stright en un shell bash es ctrl + c seguro, si necesita poner esto dentro de un script bash, es posible que necesite atrapar SIGINT y SIGTERM si desea que el usuario pueda romper su ciclo for.
fuente
git blame -w -M -C -C --line-porcelain path/to/file.txt | grep -I '^author ' | sort | uniq -ic | sort -nr
Encontré un ligero ajuste algit blame
aquí que retrata con mayor precisión las estadísticas que estaba buscando. Específicamente, la opción -M y -C -C (esas son dos C's a propósito). -M detecta movimientos dentro del archivo, y -C -C detecta líneas copiadas de otros archivos. Ver documento aquí . Para completar, -w ignora los espacios en blanco.Consulte el comando gitstats disponible en http://gitstats.sourceforge.net/
fuente
Tengo esta solución que cuenta las líneas culpables en todos los archivos de texto (excluyendo los archivos binarios, incluso los versionados):
fuente
Esto funciona en cualquier directorio de la estructura fuente del repositorio, en caso de que desee inspeccionar un determinado módulo fuente.
fuente
Adopté la respuesta principal a Powershell:
Es opcional si se ejecuta
git blame
con el-w
interruptor, lo agregué porque ignora los cambios en los espacios en blanco.El rendimiento en mi máquina estaba a favor de Powershell (~ 50s vs ~ 65s para el mismo repositorio), aunque la solución Bash se estaba ejecutando bajo WSL2
fuente
Hice mi propio script que es una combinación de @nilbus y @Alex
fuente
enter code here
estaba causando problemas ... ¿funciona esto correctamente?Función Bash que se dirige a un único archivo fuente ejecutado en MacOS.
fuente