Le repo migré GIT est beaucoup plus petit que l'original

Question

J'ai un référentiel stocké sur le système de fichiers que j'ai besoin de migrer vers un référentiel git HTTPS. Le problème est que le repo migré est plus petit que l'original, 179M contre 545 Mo pour être précis.

Voici comment la prise en pension d'origine ressemble à:

$ 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 . 

C'est la procédure de migration que j'ai suivi:

$ 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 

Et puis, si je regarde la taille des prises en pension résultant, il est 179 Mo.

Une idée de ce qui se passe ici?

Merci.

Answer 1

Les informations stockées dans le référentiel cloné sont compressées avant le démarrage effectif du clone. De cette façon, il est parfaitement compressé et conserve une petite taille tout en contenant toutes les informations du référentiel d'origine.

Le référentiel d'origine a probablement évolué avec le temps, il est donc probablement fragmenté et ne peut pas être compressé aussi efficacement. Peut-être n'est-il pas complètement emballé mais contient des objets encore non optimisés ou même des objets inaccessibles.

Vous pouvez essayer d'utiliser git gc (ou l'une de ses options les plus agressives) sur le référentiel d'origine pour voir si vous pouvez le réduire davantage.

La ligne de fond est cependant que si le processus de clonage s'est terminé sans erreurs, le référentiel cloné contiendra toutes les informations du référentiel d'origine. C'est-à-dire que chaque commit et ses données accessibles via des branches ou des tags seront inclus. Vous ne devriez donc pas avoir à vous en préoccuper.

Answer 2

Je dirais que la différence vient du fait que votre référentiel d'origine est non-vide tandis que le référentiel migré est vide. Par conséquent, 545 Mo inclut la taille de l'arbre de travail, qui est manquante dans le repo migré. Toute la différence en attribuant de taille (545MB - 179MB = 366MB) à l'arbre de travail peut être plausible pour les raisons suivantes:

1. objets dans le référentiel sont compressés tandis que dans l'arbre de travail, ils ne sont pas. Ainsi, dans un référentiel avec un historique suffisamment court et/ou des contenus fortement compressibles, l'arbre de travail peut sensiblement dépasser le contenu de .git.

2. L'arborescence de travail peut contenir des fichiers non suivis (par exemple des artefacts de construction).