Un nouveau projet open source baptisé git-meta vise à résoudre le problème croissant de la gestion des métadonnées dans les dépôts Git. Développé par l'équipe de GitButler, avec les retours des équipes de Jujutsu et Entire, git-meta se présente à la fois comme une spécification ouverte et un outil de référence en ligne de commande. Son objectif : permettre d'attacher des métadonnées fines et arbitraires aux objets Git – provenance, propriété, relecture, attestations – tout en utilisant les protocoles de transfert standard de Git.

Fonctionnement technique Contrairement à git notes, qui attache un unique blob à chaque commit, git-meta modélise de nombreux champs indépendants et mutables sur différents types de cibles : commits, branches, chemins, identifiants de changement, ou le projet lui-même. Les métadonnées sont des paires clé-valeur, avec des clés organisées en espaces de noms (namespaces) et des valeurs typées (chaînes, listes, ensembles). Chaque type possède un comportement de fusion documenté, permettant une résolution déterministe des modifications concurrentes.

L'échange des métadonnées s'effectue via des commits sur la référence refs/meta/*. Aucun serveur spécialisé ni nouveau protocole n'est nécessaire : un simple git push ou git fetch vers un dépôt distant permet de partager les métadonnées. La conception s'appuie sur les promisor remotes de Git, ce qui autorise un passage à l'échelle pour des millions d'entrées, avec un chargement à la demande.

Cas d'utilisation Le projet met en avant plusieurs cas d'usage. Pour la provenance de l'intelligence artificielle, il permet d'estampiller chaque commit avec le modèle d'IA utilisé, le hash du prompt et une référence vers la transcription, facilitant les audits ultérieurs sans avoir à parser les messages de commit. Pour la propriété du code, git-meta peut remplacer le fichier CODEOWNERS par une approche structurée : les propriétaires et relecteurs sont attachés aux chemins sous forme d'ensembles qui se fusionnent entre branches. Les commentaires et relectures peuvent être attachés directement aux commits, indépendamment de toute forge logicielle. Enfin, les attestations de tests, de builds ou les signatures peuvent être enregistrées comme des clés de premier niveau, chaque champ étant mutable indépendamment.

Flux de travail Le cycle de travail se déroule en quatre étapes : écriture locale des métadonnées dans un index rapide, sérialisation en commits sur refs/meta/*, poussée vers le dépôt distant via git push, puis récupération et fusion par les collaborateurs via git fetch. L'outil de référence est un binaire Rust unique, installable via cargo install git-meta-cli. La configuration se fait par un fichier .git-meta à la racine du projet, qui pointe vers l'URL du dépôt distant pour les métadonnées.

Indépendance vis-à-vis de Git git-meta n'exige aucune modification du cœur de Git. Il utilise des objets Git ordinaires – arbres, commits, références – et tout serveur Git acceptant les refs arbitraires peut le transporter. Les métadonnées n'alourdissent pas le clone du code source, car elles résident sur des refs distinctes. Le clonage initial utilise des récupérations partielles pour ne charger qu'un ensemble de travail.

Origine et état du projet La spécification, actuellement en version 0.1 sous licence MIT, a été proposée par GitButler, un client de contrôle de version de nouvelle génération. Elle a reçu les contributions et retours des équipes de Jujutsu, un système de contrôle de version compatible Git développé chez Google, et d'Entire, une plateforme de sessions d'agents IA. L'outil de référence implémente la spécification de bout en bout, permettant de tester les concepts. Le projet encourage l'intégration dans des outils de plus haut niveau, comme GitButler, Jujutsu ou Entire, via des hooks et alias Git.

FAQ et perspectives git-meta se distingue de git notes par sa granularité, sa prise en charge de multiples cibles et ses valeurs typées. Il ne nécessite pas de modifications de Git lui-même et peut être utilisé pour la provenance IA, ce qui constitue l'un des motifs principaux de sa création. La question du gonflement des dépôts est adressée par l'isolation des métadonnées sur des refs séparées et l'utilisation de récupérations partielles. Si nécessaire, l'historique peut être scindé ou rendu partiellement privé.