10.6 Les tripes de Git - Les protocoles de transfert

Si vous mettez en place un dépôt à accéder en lecture seule sur HTTP, c’est vraisemblablement le protocole stupide qui sera utilisé. Ce protocole est dit « stupide », car il ne nécessite aucun code spécifique à Git côté serveur durant le transfert ; le processus de récupération est une série de requêtes GET, où le client devine la structure du dépôt Git présent sur le serveur.

Suivons le processus http-fetch pour la bibliothèque simplegit :

La première chose que fait cette commande est de récupérer le fichier info/refs. Ce fichier est écrit par la commande update-server-info et c’est pour cela qu’il faut activer le crochet post-receive, sinon le transfert HTTP ne fonctionnera pas correctement :

On possède maintenant une liste des références distantes et empreintes SHA-1. Ensuite, on regarde vers quoi pointe HEAD, pour savoir sur quelle branche se placer quand on aura fini :

On aura besoin de se placer sur la branche master, quand le processus sera terminé. On est maintenant prêt à démarrer le processus de parcours. Puisque votre point de départ est l’objet commit ca82a6 que vous avez vu dans le fichier info/refs, vous commencez par le récupérer :

Vous obtenez un objet, cet objet est dans le format brut sur le serveur et vous l’avez récupéré à travers une requête HTTP GET statique. Vous pouvez le décompresser avec zlib, ignorer l’en-tête et regarder le contenu du commit :

Puis, vous avez deux autres objets supplémentaires à récupérer : cfda3b qui est l’arbre du contenu sur lequel pointe le commit que nous venons de récupérer et 085bb3 qui est le commit parent :

Cela vous donne le prochain objet commit. Récupérez l’objet arbre :

Oups, on dirait que l’objet arbre n’est pas au format brut sur le serveur, vous obtenez donc une réponse 404. On peut en déduire certaines raisons : l’objet peut être dans un dépôt suppléant ou il peut être dans un fichier groupé de ce dépôt. Git vérifie la liste des dépôts suppléants d’abord :

Si la réponse contenait une liste d’URL suppléantes, Git aurait cherché les fichiers bruts et les fichiers groupés à ces emplacements, c’est un mécanisme sympathique pour les projets qui ont dérivé d’un autre pour partager les objets sur le disque. Cependant, puisqu’il n’y a pas de suppléants listés dans ce cas, votre objet doit se trouver dans un fichier groupé. Pour voir quels fichiers groupés sont disponibles sur le serveur, vous avez besoin de récupérer le fichier objects/info/packs, qui en contient la liste (générée également par update-server-info) :

Il n’existe qu’un seul fichier groupé sur le serveur, votre objet se trouve évidemment dedans, mais vous allez tout de même vérifier l’index pour être sûr. C’est également utile lorsque vous avez plusieurs fichiers groupés sur le serveur, vous pouvez donc voir quel fichier groupé contient l’objet dont vous avez besoin :

Maintenant que vous avez l’index du fichier groupé, vous pouvez vérifier si votre objet est bien dedans car l’index liste les empreintes SHA-1 des objets contenus dans ce fichier groupé et des emplacements de ces objets. Votre objet est là, allez donc récupérer le fichier groupé complet :

Vous avez votre objet arbre, vous continuez donc le chemin des commits. Ils sont également tous contenus dans votre fichier groupé que vous venez de télécharger, vous n’avez donc pas d’autres requêtes à faire au serveur. Git récupère une copie de travail de votre branche master qui été référencée par HEAD que vous avez téléchargé au début.

Le protocole stupide est simple mais un peu inefficace, et il ne permet pas l’écriture de données du client au serveur. Le protocole intelligent est une méthode plus habituelle pour transférer des données, mais elle nécessite l’exécution sur le serveur d’un processus qui connaît Git : il peut lire les données locales et déterminer ce que le client a ou ce dont il a besoin pour générer un fichier groupé personnalisé pour lui. Il y a deux ensembles d’exécutables pour transférer les données : une paire pour téléverser des données et une paire pour en télécharger.

Cette section contient un survol basique des protocoles de transfert. Les protocoles contiennent de nombreuses autres fonctionalités, comme les compétences multi_ack ou side-band, mais leur étude est hors du sujet de ce livre. Nous avons essayé de vous donner une idée générale des échanges entre client et serveur. Si vous souhaitez en connaître davantage, vous devrez probablement jeter un œil sur le code source de Git.