El repository migrado GIT es mucho más pequeño que el original

Tengo un repository almacenado en el sistema de files que necesito migrar a un repository HTTPS git. El problema es que el repository migrado es más pequeño que el original, 179M frente a 545 MB para ser precisos.

Así es como se ve el repo original:

$ tree -L 2 .git .git/ ├── branches ├── config ├── FETCH_HEAD ├── HEAD ├── hooks ├── index ├── logs │  └── refs ├── objects │  ├── incoming_1638816568970138516.pack │  ├── incoming_2231423675192085195.pack │  ├── incoming_252567842603709439.pack │  ├── incoming_2956015230264054740.pack │  ├── incoming_3048626775278812485.pack │  ├── incoming_3322152774343971530.pack │  ├── incoming_3707332777993276763.pack │  ├── incoming_407171399829023385.pack │  ├── incoming_4072000993266381297.pack │  ├── incoming_4293432441900999175.pack │  ├── incoming_4833572675284287989.pack │  ├── incoming_4943537936436869872.pack │  ├── incoming_5555086829860720971.pack │  ├── incoming_5912835395946639495.pack │  ├── incoming_7273182803237175093.pack │  ├── incoming_7510898138918506599.pack │  ├── incoming_7865231230366160752.pack │  ├── incoming_8724975206375007218.pack │  ├── incoming_8787762604831244623.pack │  ├── incoming_9046531469688239004.pack │  ├── info │  └── pack └── refs ├── heads ├── remotes └── tags $ git branch -a cli max codefactoring * master new-load-configuration new-loader plugins_dev remotes/origin/cli remotes/origin/max remotes/origin/codefactoring remotes/origin/master $ du -sh . 545M . 

Este es el procedimiento de migration que he seguido:

 $ mkdir temp_dir && cd temp_dir $ git clone --mirror /path/to/original/repo $ cd /path/to/original/repo $ git remote add new-origin https://myuser@my.source.server/myuser/repo.git $ git push new-origin --mirror 

Y luego, si miro el tamaño del repository resultante, es 179MB.

¿Alguna idea de lo que está pasando aquí?

Gracias.

La información almacenada en el repository clonado se empaqueta antes de que comience realmente el clon. De esta forma, está perfectamente comprimido y mantiene un tamaño pequeño al time que contiene toda la información del repository original.

Sin embargo, el repository original probablemente evolucionó con el time, por lo que posiblemente esté fragmentado y no se pueda empaquetar de manera tan eficiente. Tal vez no está completamente empaquetado pero contiene objects aún no optimizados o incluso objects que ya no se pueden alcanzar.

Podría intentar usar git gc (o una de sus opciones más agresivas) en el repository original para ver si puede networkingucirlo aún más.

Sin embargo, la conclusión es que si el process de clonación se completó sin errores, el repository clonado contendrá toda la información del repository original. Es decir, se includeán todas las confirmaciones y sus datos a los que se pueda acceder utilizando twigs o tags. Entonces no deberías preocuparte por eso.

Yo diría que la diferencia se debe a que su repository original no es puro mientras que el repository migrado es simple. Por lo tanto, 545 MB incluye el tamaño del tree de trabajo, que falta en el repository migrado. Atribuir toda la diferencia de tamaño (545MB – 179MB = 366MB) al tree de trabajo puede ser plausible por las siguientes razones:

  1. Los objects en el repository se comprimen mientras que en el tree de trabajo no están comprimidos. Por lo tanto, en un repository con un historial suficientemente corto y / o con contenidos fuertemente comprimibles, el tree de trabajo puede exceder notablemente los contenidos de .git .

  2. El tree de trabajo puede contener files sin seguimiento (por ejemplo, artefactos de construcción).