tag - ¿Por qué mi repositorio git es tan grande?

git push tag

Question

145M = .git / objects / pack /

Escribí un guión para sumar los tamaños de las diferencias de cada confirmación y la confirmación antes de ir hacia atrás desde la punta de cada rama. Obtengo 129 MB, que es sin compresión y sin tener en cuenta los mismos archivos en las sucursales y la historia común entre las sucursales.

Git toma todas esas cosas en cuenta, así que esperaría un repositorio mucho más pequeño. Entonces, ¿por qué es .git tan grande?

Hice:

git fsck --full
git gc --prune=today --aggressive
git repack

Para responder cuántos archivos / confirmaciones tengo, tengo 19 sucursales y 40 archivos en cada una. 287 commits, encontrados usando:

git log --oneline --all|wc -l

No debería tomar 10''s de megabytes para almacenar información sobre esto.

Answer 1

¿ Intentó usar git repack ?

Answer 2

¿Estás seguro de que estás contando solo los archivos .pack y no los archivos .idx? Están en el mismo directorio que los archivos .pack, pero no tienen ninguno de los datos del repositorio (como indica la extensión, no son más que índices para el paquete correspondiente; de ​​hecho, si conoce el comando correcto, puede recupérelos fácilmente desde el archivo del paquete, y git lo hace al clonar, ya que solo un archivo del paquete se transfiere usando el protocolo git nativo).

Como muestra representativa, eché un vistazo a mi clon local del repositorio Linux-2.6:

$ du -c *.pack
505888  total

$ du -c *.idx
34300   total

Lo que indica que una expansión de alrededor del 7% debería ser común.

También están los archivos fuera de objects/ ; en mi experiencia personal, de ellos index y gitk.cache tienden a ser los más grandes (totalizando 11M en mi clon del repositorio linux-2.6).

Answer 3

Algunos scripts que uso:

git-fatfiles

git rev-list --all --objects | /
    sed -n $(git rev-list --objects --all | /
    cut -f1 -d'' '' | /
    git cat-file --batch-check | /
    grep blob | /
    sort -n -k 3 | /
    tail -n40 | /
    while read hash type size; do 
         echo -n "-e s/$hash/$size/p ";
    done) | /
    sort -n -k1

...
89076 images/screenshots/properties.png
103472 images/screenshots/signals.png
9434202 video/parasite-intro.avi

Si desea más líneas, consulte también la versión de Perl en una respuesta vecina: https://.com/a/45366030/266720

git-erradicar (para video/parasite.avi ):

git filter-branch -f  --index-filter /
    ''git rm --force --cached --ignore-unmatch video/parasite-intro.avi'' /
     -- --all
rm -Rf .git/refs/original && /
    git reflog expire --expire=now --all && /
    git gc --aggressive && /
    git prune

Nota: el segundo script está diseñado para eliminar por completo la información de Git (incluida toda la información de los reflogs). Usar con precaución.

Answer 4

El script git-fatfiles de la respuesta de Vi es encantador si quieres ver el tamaño de todos tus blobs, pero es tan lento que no se puede usar. Quité el límite de salida de 40 líneas e intenté usar toda la RAM de mi computadora en lugar de terminar. Así que lo reescribí: esto es miles de veces más rápido, tiene funciones adicionales (opcional) y se eliminó algún error extraño: la versión anterior proporcionaría recuentos inexactos si suma el resultado para ver el espacio total utilizado por un archivo.

#!/usr/bin/perl
use warnings;
use strict;
use IPC::Open2;
use v5.14;

# Try to get the "format_bytes" function:
my $canFormat = eval {
    require Number::Bytes::Human;
    Number::Bytes::Human->import(''format_bytes'');
    1;
};
my $format_bytes;
if ($canFormat) {
    $format_bytes = /&format_bytes;
}
else {
    $format_bytes = sub { return shift; };
}

# parse arguments:
my ($directories, $sum);
{
    my $arg = $ARGV[0] // "";
    if ($arg eq "--sum" || $arg eq "-s") {
        $sum = 1;
    }
    elsif ($arg eq "--directories" || $arg eq "-d") {
        $directories = 1;
        $sum = 1;
    }
    elsif ($arg) {
        print "Usage: $0 [ --sum, -s | --directories, -d ]/n";
        exit 1;
    } 
}

# the format is [hash, file]
my %revList = map { (split('' '', $_))[0 => 1]; } qx(git rev-list --all --objects);
my $pid = open2(my $childOut, my $childIn, "git cat-file --batch-check");

# The format is (hash => size)
my %hashSizes = map {
    print $childIn $_ . "/n";
    my @blobData = split('' '', <$childOut>);
    if ($blobData[1] eq ''blob'') {
        # [hash, size]
        $blobData[0] => $blobData[2];
    }
    else {
        ();
    }
} keys %revList;
close($childIn);
waitpid($pid, 0);

# Need to filter because some aren''t files--there are useless directories in this list.
# Format is name => size.
my %fileSizes =
    map { exists($hashSizes{$_}) ? ($revList{$_} => $hashSizes{$_}) : () } keys %revList;


my @sortedSizes;
if ($sum) {
    my %fileSizeSums;
    if ($directories) {
        while (my ($name, $size) = each %fileSizes) {
            # strip off the trailing part of the filename:
            $fileSizeSums{$name =~ s|/[^/]*$||r} += $size;
        }
    }
    else {
        while (my ($name, $size) = each %fileSizes) {
            $fileSizeSums{$name} += $size;
        }
    }

    @sortedSizes = map { [$_, $fileSizeSums{$_}] }
        sort { $fileSizeSums{$a} <=> $fileSizeSums{$b} } keys %fileSizeSums;
}
else {
    # Print the space taken by each file/blob, sorted by size
    @sortedSizes = map { [$_, $fileSizes{$_}] }
        sort { $fileSizes{$a} <=> $fileSizes{$b} } keys %fileSizes;

}

for my $fileSize (@sortedSizes) {
    printf "%s/t%s/n", $format_bytes->($fileSize->[1]), $fileSize->[0];
}

Nombre este git-fatfiles.pl y ejecútelo. Para ver el espacio en disco utilizado por todas las revisiones de un archivo, use la opción --sum . Para ver lo mismo, pero para los archivos dentro de cada directorio, use la opción --directories . Si instala el Number::Bytes::Human cpan (ejecute "cpan Number :: Bytes :: Human"), los tamaños se formatearán: "21M /path/to/file.mp4".

Answer 5

Esto puede suceder si agregaste una gran cantidad de archivos accidentalmente y los organizaste, no necesariamente los cometiste. Esto puede suceder en una aplicación de rails cuando ejecuta bundle install --deployment y luego accidentalmente git add . luego ves todos los archivos agregados en vendor/bundle , los desglosas pero ya ingresaron en el historial de git, por lo que debes aplicar la respuesta de Vi y cambiar el video/parasite-intro.avi por vendor/bundle luego ejecutar el segundo comando que proporciona.

Puede ver la diferencia con git count-objects -v que en mi caso antes de aplicar el script tenía un paquete de tamaño: de 52K y después de aplicarlo era 3.8K.

Answer 6

Hace poco saqué el repositorio remoto equivocado en el local ( git remote add ... y git remote update ). Después de eliminar la referencia remota no deseada, las ramas y las etiquetas, todavía tenía 1.4 GB (!) De espacio desperdiciado en mi repositorio. Solo pude deshacerme de esto al git clone file:///path/to/repository con git clone file:///path/to/repository . Tenga en cuenta que el file:// hace una gran diferencia al clonar un repositorio local: solo los objetos a los que se hace referencia se copian, no toda la estructura del directorio.

Editar: Este es el trazador de líneas de Ian para recrear todas las ramas en el nuevo repositorio:

d1=#original repo
d2=#new repo (must already exist)
cd $d1
for b in $(git branch | cut -c 3-)
do
    git checkout $b
    x=$(git rev-parse HEAD)
    cd $d2
    git checkout -b $b $x
    cd $d1
done

Answer 7

Otros objetos de git almacenados en .git incluyen árboles, confirmaciones y etiquetas. Los commits y las etiquetas son pequeños, pero los árboles pueden ser grandes, especialmente si tiene una gran cantidad de archivos pequeños en su repositorio. ¿Cuántos archivos y cuántos commit tienes?

Answer 8

Si quieres encontrar qué archivos ocupan espacio en tu repositorio de git, ejecuta

git verify-pack -v .git/objects/pack/*.idx | sort -k 3 -n | tail -5

A continuación, extraiga la referencia de blob que ocupa más espacio (la última línea) y verifique el nombre de archivo que ocupa tanto espacio

git rev-list --objects --all | grep <reference>

Incluso podría ser un archivo que eliminó con git rm , pero git lo recuerda porque todavía hay referencias a él, como etiquetas, controles remotos y reflog.

Una vez que sepa de qué archivo quiere deshacerse, le recomiendo usar git forget-blob

https://ownyourbits.com/2017/01/18/completely-remove-a-file-from-a-git-repository-with-git-forget-blob/

Es fácil de usar, solo hazlo

git forget-blob file-to-forget

Esto eliminará todas las referencias de git, eliminará el blob de cada confirmación en el historial y ejecutará la recolección de basura para liberar el espacio.

Answer 9

Solo para tu información, la razón más grande por la que puedes terminar con objetos no deseados que se guardan es que git mantiene un reflog.

El reflog está ahí para salvar su trasero cuando accidentalmente borre su rama principal o de alguna manera dañe catastróficamente su repositorio.

La forma más fácil de solucionar esto es truncar los reflogs antes de comprimirlos (solo asegúrese de no volver a ninguna de las confirmaciones en el reflog).

git gc --prune=now --aggressive
git repack

Esto es diferente de git gc --prune=today en que vence todo el reflog inmediatamente.

Answer 10

Vale la pena comprobar el stacktrace.log. Básicamente es un registro de error para el seguimiento de confirmaciones que fallaron. Recientemente descubrí que mi stacktrace.log es 65.5GB y mi aplicación es 66.7GB.

Answer 11

antes de hacer git filter-branch & git gc deberías revisar las etiquetas que están presentes en tu repositorio. Cualquier sistema real que tenga etiquetado automático para cosas como la integración continua y las implementaciones hará que los objetos no objetados sigan siendo refrendados por estas etiquetas, por lo tanto, no puedo eliminarlos y todavía te preguntarás por qué el tamaño del repositorio sigue siendo tan grande.

La mejor manera de deshacerse de todas las cosas no deseadas es ejecutar git-filter & git gc y luego enviar master a un nuevo repositorio desnudo. El nuevo repositorio desnudo tendrá el árbol limpio.

Answer 12

git gc ya hace una git repack así que no tiene sentido volver a empacar manualmente a menos que le esté pasando algunas opciones especiales.

El primer paso es ver si la mayoría del espacio es (como sería normalmente el caso) su base de datos de objetos.

git count-objects -v

Esto debería dar un informe de cuántos objetos desempaquetados hay en su repositorio, cuánto espacio ocupan, cuántos archivos de paquete tienen y cuánto espacio ocupan.

Idealmente, después de un reempaquetado, no tendría objetos desempaquetados y un archivo de paquete, pero es perfectamente normal tener algunos objetos que no son directamente referenciados por las ramas actuales todavía presentes y desempaquetadas.

Si tiene un único paquete grande y desea saber qué ocupa el espacio, puede enumerar los objetos que componen el paquete junto con la forma en que se almacenan.

git verify-pack -v .git/objects/pack/pack-*.idx

Tenga en cuenta que verify-pack toma un archivo de índice y no el archivo del paquete en sí. Esto proporciona un informe de cada objeto en el paquete, su tamaño real y su tamaño compacto, así como información sobre si ha sido ''deltificado'' y si es así el origen de la cadena delta.

Para ver si hay objetos inusualmente grandes en su repositorio, puede ordenar la salida numéricamente en la tercera de las cuatro columnas (por ej. | sort -k3n ).

A partir de este resultado, podrá ver el contenido de cualquier objeto utilizando el comando git show , aunque no es posible ver exactamente en qué parte del historial de confirmación del repositorio se hace referencia al objeto. Si necesita hacer esto, intente algo de esta pregunta .