Monorepo Git

Cette page est une étude pour trouver la meilleure solution de faire un monorepo Git, ou plus exactement, idéalement, un repo Git qui serait à la fois :

• un monorepo (qu’on puisse télécharger en une seule fois)
• un multi-repo où certains dossiers serait des repo Git ayant leur historique autonome.

Dans les contraintes que j’impose, il faut :

• que les solutions potentielles soient possibles en l’état actuel de Git ou, a maximum, un programme Bourne shell d’une taille relativement faible (afin d’être compatible sur un maximum de plate-formes et qu’il reste lisible et compréhensible),
• il peut y avoir une forme d’équivalence entre deux états "monorepo" et "multirepo" évenutuellement disticts mais switchable avec une commande,
• les commandes standard Git devraient fonctionner, au moins dans un certain état "monorepo"/"multirepo" s’ils sont distincts,
• la performance doit rester acceptable (je sais, c’est vague et ça dépend des situations).

Les cas d’usage que je prévoie sont :

• pour Archéo Lex : pouvoir aggréger l’ensemble des lois françaises dans un seul monorepo mais en ayant la possibilité de télécharger seulement des sous-ensembles, par exemples les décrets,
• pour MediaWiki : pouvoir avoir le logiciel de base (un repo) avec les extensions (chacun dans un repo) où le déploiement est un monorepo comportant la version de base + les extensions déployées dans une certaine version, éventuellement patchée.

Briques de base

Sous-modules Git (voir gitsubmodules(7))

Espaces de noms Git (voir gitnamespaces(7))

Dépôt distant de type ext (voir git-remote-ext(1))

Ilôts delta (delta islands) (voir git-pack-objects(1))

Les options de configuration, par exemple "diff.submodule"