Organisation de dépôts liés

Pour un projet perso, j'ai pour le moment plusieurs dépôts git organisés ainsi :

• (A) Dépôt principal, code C++ de la bibliothèque ;
• (B) Dépôt des fichiers de tests (séparés car ce sont des gros fichiers) ;
• (C) Dépôts des interface pour les autres langages (un dépôt pour Python, un pour Julia, un pour Rust, …) ;
• (D) Dépôt contenant un outil en ligne de commande utilisant cette bibliothèque.

Pour l'instant, les dépôts de (B) à (D) sont des sous-modules git du dépôt principal (A). Je me demande s'il ne vaudrait pas mieux que tous les dépôts soit regroupés en un seul, simplement séparé en sous-dossiers.

Avantages de la séparation en sous-modules

• Économie de bande passante pour le dépôt (B) ;
• Intégration aux gestionnaires de paquets spécifiques pour (C) ;
• (C) et (D) peuvent être mis à jour de manière indépendante de (A) ;

Inconvénients de cette séparation

• Développement plus compliqué, où il faut jongler entre les dépôts ;
• Installation et mise à jour depuis les sources plus compliquée, il faut penser à lancer des commandes avec git submodule, et on ne peut pas utiliser les archives crées par git facilement ;

Mes questions

Que pensez-vous de cette séparation ? Est-elle pertinente ? Utilisable ?

Y a-t-il un moyen de faire générer à Github des archives zip qui contiennent le contenu de certains sous-modules ?

Installation et mise à jour depuis les sources plus compliquée, il faut penser à lancer des commandes avec git submodule, et on ne peut pas utiliser les archives crées par git facilement ;

Il n'y a pas moyen de créer un script.sh avec les commandes git submodule dedans ? Comme ça tu n'aurais plus qu'une commande à faire : bash script.sh.

Que pensez-vous de cette séparation ? Est-elle pertinente ? Utilisable ?

Je pense qu'elle est pertinente et utilisable.

Y a-t-il un moyen de faire générer à Github des archives zip qui contiennent le contenu de certains sous-modules ?

Lorsque tu crées une release de ton dépôt (par exemple une nouvelle version), GitHub crée automatiquement un fichier ZIP contenant tout le dépôt. Je ne sais pas trop si c'est ce que tu veux ?

Salut,

Il n'y a pas moyen de créer un script.sh avec les commandes git submodule dedans ?

C'est plus subtil que ça, à chaque action "classique", il y a le pendant à appliquer sur les submodules. Donc il faudrait faire un script pour chacune de ces actions différentes (qu'on ne fait jamais à la suite). L'intérêt serait donc nul.

Le problème, c'est de savoir si tu as vraiment besoin des avantages que tu listes. Si oui, tu ne peux pas avoir le beurre et l'argent du beurre, et tu devras passer par les commandes git submodules. D'un côté, c'est pas forcément pratique, mais c'est leur existence qui garantit les avantages que tu listes… Si tu te retrouves à toujours reporter les actions sur les submodules en te faisant un peu chier au passage, c'est peut être que tu n'as pas besoin des submodules.

Les dépôts (B) et (D) contiennent des fichiers autre que le format texte ? Tu risques d'alourdir ton dépôt principal (A).

EDIT : Je me souviens d'un projet d'étude où on avait galéré avec toute la documentation (word, pdf, excel etc) intégré dans le dépôt. Il était devenu quasi impossible de faire des pull.

Lorsque tu crées une release de ton dépôt (par exemple une nouvelle version), GitHub crée automatiquement un fichier ZIP contenant tout le dépôt. Je ne sais pas trop si c'est ce que tu veux ?

Ce fichier zip ne contient pas les sous-modules je crois. Dans tous les cas, je voudrais bien intégrer (C) et (D), mais pas (B) dans cette archive.

Les dépôts (B) et (D) contiennent des fichiers autre que le format texte ? Tu risques d'alourdir ton dépôt principal (A).

(B) oui, mais (D) non. (D) contient un exemple de binaire utilisant (A).

Je crois que je vais rester comme ça encore un peu. Je verrai bien si ça devient vraiment ingérable.

Tu as pensé plutôt à utiliser l'outil « repo » de Google ? Je pense qu'il pourrait t'intéresser, en tout cas à mon travail il permet de gérer facilement ce genre de cas.