Dédupliquez les fourches Git sur un serveur

Maintenant, le même fichier "énorme" réside dans les deux fourches du développeur sur le serveur. Il ne crée pas de lien physique automatiquement

En fait, avec Git 2.20, ce problème pourrait disparaître, à cause des îles delta , une nouvelle façon de faire des calculs delta afin qu'un objet qui existe dans un fork ne soit pas transformé en delta par rapport à un autre objet qui n'apparaît pas dans le même référentiel fork .

Voir commit fe0ac2f, commit 108f530, commit f64ba53 (16 août 2018) par Christian Couder (chriscool ).
Aidé par :Jeff King (peff ), et Duy Nguyen (pclouds ).
Voir commit 9eb0986, commit 16d75fa, commit 28b8a73, commit c8d521f (16 août 2018) par Jeff King (peff ).
Aidé par :Jeff King (peff ), et Duy Nguyen (pclouds ).

Ajouter delta-islands.{c,h}

Les fournisseurs d'hébergement qui permettent aux utilisateurs de « bifurquer » des référentiels existants veulent que ces bifurcations partagent autant d'espace disque que possible.

Les alternatives sont une solution existante pour conserver tous les objets de toutes les fourches dans un référentiel central unique, mais cela peut présenter certains inconvénients.
Surtout lors de l'empaquetage du référentiel central, des deltas seront créés entre les objets de différentes fourches.

Cela peut rendre le clonage ou la récupération d'un fork beaucoup plus lent et beaucoup plus gourmand en CPU, car Git devra peut-être calculer de nouveaux deltas pour de nombreux objets afin d'éviter d'envoyer des objets à partir d'un fork différent.

Étant donné que l'inefficacité survient principalement lorsqu'un objet est deltifié par rapport à un autre objet qui n'existe pas dans le même fork, nous divisons les objets en ensembles qui apparaissent dans le même fork et définissons des "îlots delta".
Lors de la recherche d'une base delta, nous n'autorisons pas un objet en dehors de la même île à être considéré comme sa base.

Ainsi, les "îles delta" sont un moyen de stocker des objets de différents forks dans le même référentiel et packfile sans avoir de deltas entre les objets de différents forks.

Ce patch implémente le mécanisme des îlots delta dans "delta-islands.{c,h} ", mais ne l'utilise pas encore.

Quelques nouveaux champs sont ajoutés dans 'struct object_entry ' dans "pack-objects.h " cependant.

Voir Documentation/git-pack-objects.txt :Île Delta :

ÎLES DELTA

Si possible, pack-objects essaie de réutiliser les deltas existants sur disque pour éviter d'avoir à en rechercher de nouveaux à la volée. Il s'agit d'une optimisation importante pour les récupérations de service, car cela signifie que le serveur peut éviter de gonfler la plupart des objets et simplement envoyer les octets directement depuis le disque.

Cette optimisation ne peut pas fonctionner lorsqu'un objet est stocké sous forme de delta par rapport à une base que le récepteur n'a pas (et que nous n'envoyons pas déjà). Dans ce cas, le serveur "casse" le delta et doit en trouver un nouveau, qui a un coût CPU élevé. Par conséquent, il est important pour les performances que l'ensemble d'objets dans les relations delta sur disque corresponde à ce qu'un client récupérerait.

Dans un référentiel normal, cela a tendance à fonctionner automatiquement.
Les objets sont principalement accessibles à partir des branches et des balises, et c'est ce que les clients récupèrent. Tous les deltas que nous trouvons sur le serveur sont susceptibles d'être entre des objets que le client a ou aura.

Mais dans certaines configurations de référentiel, vous pouvez avoir plusieurs groupes de conseils de référence liés mais distincts, les clients ayant tendance à récupérer ces groupes indépendamment.

Par exemple, imaginez que vous hébergez plusieurs "forks" d'un référentiel dans un seul magasin d'objets partagé et que vous laissez les clients les afficher comme des référentiels séparés via GIT_NAMESPACE ou des référentiels séparés à l'aide du mécanisme alternatif.

Un repack naïf peut trouver que le delta optimal pour un objet est contre une base qui ne se trouve que dans une autre fourche.
Mais lorsqu'un client récupère, il n'aura pas l'objet de base et nous devrons trouver un nouveau delta à la volée.

Une situation similaire peut exister si vous avez de nombreuses références en dehors de refs/heads/ et refs/tags/ qui pointent vers des objets connexes (par exemple, refs/pull ou refs/changes utilisé par certains hébergeurs). Par défaut, les clients ne récupèrent que les en-têtes et les balises, et les deltas par rapport aux objets trouvés uniquement dans ces autres groupes ne peuvent pas être envoyés tels quels.

Les îles Delta résolvent ce problème en vous permettant de regrouper vos références en "îles" distinctes .

Pack-objects calcule quels objets sont accessibles depuis quelles îles, et refuse de faire un delta à partir d'un objet A contre une base qui n'est pas présente dans tous les A les îles. Cela se traduit par des packs légèrement plus grands (parce que nous manquons certaines opportunités de delta), mais garantit qu'une récupération d'une île n'aura pas à recalculer les deltas à la volée en raison du franchissement des frontières des îles.

Un effet secondaire cependant :certaines commandes étaient plus verbeuses. Git 2.23 (Q3 2019) corrige ce problème.

Voir commit bdbdf42 (20 juin 2019) par Jeff King (peff ).

delta-islands :respecter progress drapeau

Le code de l'île delta imprime toujours "Marked %d islands ", même si la progression a été supprimée avec --no-progress ou en envoyant stderr à un non-tty.

Passons un progress booléen en load_delta_islands() .
Nous faisons déjà la même chose pour le compteur de progression dans resolve_tree_islands() .

J'ai décidé de faire ceci :

 shared-objects-database.git/
foo.git/
  objects/info/alternate (will have ../../shared-objects-database.git/objects)
bar.git/
  objects/info/alternate (will have ../../shared-objects-database.git/objects)
baz.git/
  objects/info/alternate (will have ../../shared-objects-database.git/objects)

Tous les forks auront une entrée dans leur fichier objects/info/alternates qui donne un chemin relatif vers le référentiel de base de données des objets.

Il est important de faire de la base de données d'objets un référentiel, car nous pouvons enregistrer des objets et des références de différents utilisateurs ayant un référentiel du même nom.

Étapes :

1. git init --bare shared-object-database.git

2. J'exécute les lignes de code suivantes soit chaque fois qu'il y a un push vers n'importe quel fork (via la post-réception) ou en exécutant un cronjob

   for r in list-of-forks
       do
   

   (cd "$r" &&git push ../shared-objects-database.git "refs/:refs/remotes/$r/ " &&echo ../../shared-objects-database.git/objects>objects/info/alternates# à sauvegarder j'ajoute les objets "gros" aux alternatives à chaque fois)done

Ensuite, dans le prochain "git gc", tous les objets dans les fourches qui existent déjà dans alternate seront supprimés.

git repack -adl est aussi une option !

De cette façon, nous économisons de l'espace afin que deux utilisateurs poussant les mêmes données sur leurs fourches respectives sur le serveur partagent les objets.

Nous devons définir le gc.pruneExpire variable jusqu'à never dans la base de données d'objets partagés. Juste pour être sûr !

Pour élaguer occasionnellement des objets, ajoutez toutes les fourches en tant que télécommandes au partagé, récupérez et élaguez ! Git fera le reste !

(J'ai enfin trouvé une solution qui fonctionne pour moi ! (Non testé en production ! :p Merci à ce post.)