Contexte et limites de Git

Git a été créé en 2005 pour le noyau Linux, un projet de 43 millions de lignes de code. Cette conception repose sur des hypothèses de taille et de fréquence de mise à jour qui ne correspondent plus aux monorépos actuels, certains atteignant plusieurs milliards de lignes. L’essor des agents de développement automatisés multiplie les branches actives et accélère les cycles de clone, ce qui augmente la contention sur les opérations de fusion.

Les services d’hébergement Git traditionnels conservent les dépôts sous forme d’objets Git sur disque, puis exposent un service qui traduit les requêtes du protocole Git. Cette pile, bien que fonctionnelle, ne se prête pas à une mise à l’échelle horizontale sans duplication lourde des dépôts et sans risque d’interférence entre clients.

Architecture du moteur de stockage d’ERSC

ERSC propose de conserver le protocole Git côté client tout en remplaçant le backend de stockage par un moteur propriétaire. Au lieu de persister les objets Git, le moteur indexe les changements dans une couche de stockage distribuée, répliquée sur plusieurs nœuds. Cette approche permet d’ajouter des nœuds de façon linéaire, car chaque nouveau serveur accède à la même couche d’index sans devoir copier l’intégralité du dépôt.

Le diagramme interne mentionne une API GraphQL qui orchestre les métadonnées de version, séparée du flux de données Git. Cette séparation rend possible la mise en cache fine‑grained des métadonnées et la gestion asynchrone des transferts de blobs, réduisant ainsi le temps de clonage dans les environnements cloud où les instances sont éphémères.

En ne stockant pas les dépôts Git « bruts », le système évite les goulets d’étranglement liés à la lecture séquentielle de gros fichiers pack. Le moteur peut appliquer des stratégies de compression et de déduplication adaptées aux monorépos, ce qui diminue l’empreinte disque et le trafic réseau.

Stratégie d’adoption avec Jujutsu

ERSC s’appuie sur le projet Jujutsu (jj), un VCS capable de parler plusieurs backends. En mode standard, jj utilise le backend Git, ce qui permet aux développeurs de continuer à employer leurs outils habituels. Lorsque le backend passe à l’infrastructure d’ERSC, le même client jj transmet les requêtes via le protocole Git, mais le serveur les redirige vers le moteur propriétaire.

Cette double compatibilité crée un chemin de migration progressif : les équipes peuvent tester le nouveau stockage sans modifier leurs pipelines CI/CD, puis basculer entièrement lorsque les performances ou les exigences de conformité le justifient. Le fait que jj ne possède pas encore de protocole natif dédié ne bloque pas la démarche, car le protocole Git agit comme un pont stable.

Perspectives et défis

Le modèle d’ERSC promet une scalabilité horizontale et une isolation des charges entre clients, mais il repose sur la robustesse du moteur de stockage distribué. La cohérence des métadonnées sous forte concurrence reste un point d’attention, notamment lors de merges massifs générés par les agents. De plus, la dépendance à une API GraphQL introduit une couche supplémentaire qui doit être sécurisée contre les injections de requêtes.

Enfin, l’adoption large dépendra de la capacité du projet jj à implémenter un protocole natif ou à étendre son support aux backends propriétaires. Sans cet avancement, les organisations devront accepter la coexistence de deux systèmes, ce qui peut compliquer la gouvernance des accès. Malgré ces incertitudes, la séparation du protocole Git et du stockage représente une évolution technique claire face aux limites historiques de Git.