Para buscar confirmaciones duplicadas de cometer $hash
, con exclusión de combinación se compromete:
git rev-list --no-merges --all | xargs -r git show | git patch-id \
| grep ^$(git show $hash|git patch-id|cut -c1-40) | cut -c42-80 \
| xargs -r git show -s --oneline
Para buscar el duplicado de una combinación de cometer $mergehash
, reemplace $(git show $hash|git patch-id|cut -c1-40)
anterior por uno de los dos ID de parche (1ª columna) dado por git diff-tree -m -p $mergehash | git patch-id
. Corresponden a los diffs de la fusión se comprometen con cada uno de sus dos padres.
para encontrar duplicados de todas las confirmaciones, con exclusión de combinación se compromete:
git rev-list --no-merges --all | xargs -r git show | git patch-id \
| sort | uniq -w40 -D | cut -c42-80 \
| xargs -r git log --no-walk --pretty=format:"%h %ad %an (%cn) %s" --date-order --date=iso
La búsqueda para las confirmaciones duplicadas puede ser extendido o limitado por el cambio de los argumentos a git rev-list
, que acepta numerosas opciones. Por ejemplo, para limitar la búsqueda a una rama específica, especifique su nombre en lugar de la opción --all
; o para buscar en los últimos 100 commits, pase los argumentos HEAD ^HEAD~100
.
Tenga en cuenta que estos comandos son rápidos ya que no utilizan ningún bucle de shell y los procesos por lotes se comprometen.
Para incluir las asignaciones de fusión, elimine la opción --no-merges
, y reemplace xargs -r git show
por xargs -r -L1 git diff-tree -m -p
. Esto es mucho más lento porque git diff-tree
se ejecuta una vez por confirmación.
Explicación:
La primera línea genera un mapa de los ID de parche con los hashes cometer (datos 2-columna, de 40 caracteres cada uno).
La segunda línea solo mantiene hashes de confirmación (2da columna) correspondientes a los ID de parche duplicados (1ra columna).
La última línea imprime información personalizada sobre las confirmaciones duplicadas.
Esta es una característica fascinante. Por curiosidad, ¿qué tan atrás en el pasado pretendes mirar? Pude ver algunos usos de integración creativa para esto (es decir, "mi colaborador no sabe cómo volver a establecer la base"), pero a lo largo de la historia sería menos eficaz ...? – Christopher
El problema apareció en una historia de una rama de una semana, por lo que mi caso de uso fue bastante amable (git log -p fue suficiente). El comentario del id del parche me dio curiosidad, sin embargo ... Buscar toda la historia podría ser doloroso. – bsb