Como se menciona en esta respuesta SO , ¡en git gc
realidad puede aumentar el tamaño del repositorio!
Ver también este hilo
Ahora git tiene un mecanismo de seguridad para no eliminar objetos sin referencia de inmediato cuando se ejecuta ' git gc
'.
De forma predeterminada, los objetos sin referencia se guardan durante un período de 2 semanas. Esto es para facilitarle la recuperación de ramas o confirmaciones borradas accidentalmente, o para evitar una carrera en la que un objeto recién creado en el proceso de ser pero aún no referenciado podría ser eliminado por un git gc
proceso que se ejecuta en paralelo.
Entonces, para dar ese período de gracia a los objetos empaquetados pero sin referencia, el proceso de reempaquetado empuja esos objetos sin referencia fuera del paquete a su forma suelta para que puedan envejecer y eventualmente podar.
Sin embargo, los objetos que quedan sin referencia no suelen ser tantos. Tener 404855 objetos sin referencia es bastante, y enviar esos objetos en primer lugar a través de un clon es estúpido y una completa pérdida de ancho de banda de la red.
De todos modos ... Para resolver su problema, simplemente necesita ejecutar ' git gc
' con el --prune=now
argumento para deshabilitar ese período de gracia y deshacerse de esos objetos sin referencia de inmediato (seguro solo si no se están realizando otras actividades de git al mismo tiempo, lo que debería ser fácil de asegurar en una estación de trabajo).
Y por cierto, usando ' git gc --aggressive
' con una versión posterior de git (o ' git repack -a -f -d --window=250 --depth=250
')
El mismo hilo menciona :
git config pack.deltaCacheSize 1
Eso limita el tamaño de la caché delta a un byte (desactivándolo efectivamente) en lugar del valor predeterminado de 0, lo que significa ilimitado. Con eso, puedo volver a empaquetar ese repositorio usando el git repack
comando anterior en un sistema x86-64 con 4GB de RAM y usando 4 subprocesos (este es un núcleo cuádruple). Sin embargo, el uso de memoria residente crece a casi 3.3GB.
Si su máquina es SMP y no tiene suficiente RAM, puede reducir la cantidad de subprocesos a solo uno:
git config pack.threads 1
Además, puede limitar aún más el uso de memoria con --window-memory argument
to ' git repack
'.
Por ejemplo, el uso --window-memory=128M
debe mantener un límite superior razonable en el uso de la memoria de búsqueda delta, aunque esto puede resultar en una coincidencia delta menos óptima si el repositorio contiene muchos archivos grandes.
En el frente de la rama de filtro, puede considerar (con cautela) este script
#!/bin/bash
set -o errexit
# Author: David Underhill
# Script to permanently delete files/folders from your git repository. To use
# it, cd to your repository's root and then run the script with a list of paths
# you want to delete, e.g., git-delete-history path1 path2
if [ $# -eq 0 ]; then
exit 0
fi
# make sure we're at the root of git repo
if [ ! -d .git ]; then
echo "Error: must run this script from the root of a git repository"
exit 1
fi
# remove all paths passed as arguments from the history of the repo
files=$@
git filter-branch --index-filter "git rm -rf --cached --ignore-unmatch $files" HEAD
# remove the temporary history git-filter-branch otherwise leaves behind for a long time
rm -rf .git/refs/original/ && git reflog expire --all && git gc --aggressive --prune