Combinaison de plusieurs référentiels .git tout en conservant les informations de validation basées sur les fichiers

Question

En provenance de CVS, nous avons un répertoire de packages, qui contient des référentiels .git uniques pour chaque package. Malheureusement, ils ne sont pas aussi indépendants que les propriétaires CVS d'origine pensaient, donc généralement ils sont tous retirés ensemble et combinés en un ensemble complet dans n'importe quel système de gestion de versions que vous utilisez en tant que développeur.

Combining multiple git repositories et http://progit.org/book/ch6-7.html m'a déjà dit comment les combiner dans un seul référentiel de .git, donc au lieu de:

packages/intranet-asus-client/.git 
packages/intranet-timesheet/.git 
packages/intranet-core/.git 

il ressemble

packages/.git 
packages/intranet-core (without .git, and so on). 

git log en paquets me montre l'ensemble commit histoire (grande), mais ce qui manque est:

1. Fichier b ased histoire git comme git log --pretty=oneline -- intranet-core/intranet-core.info. Il ne me montre que les commits que j'ai faits dans le dépôt combiné (ce qui signifie en /packages/.git)
2. Aucune branche ou étiquette. J'ai l'intuition que je devrais créer une branche dans /packages/.git pour chaque branche présente dans /packages/acs-kernel/.git et ainsi de suite. Mais qu'en est-il des tags?

Ou est-ce un de ces excellents exemples où les sous-modules seraient vraiment utiles? Malheureusement, cela signifie pour nous (comme nous faisons des correctifs clients réguliers pour les paquets) que nous aurions à fork (nous utilisons github ....) tous les paquets .git remote repository dans un dépôt privé et utiliser nos propres branches clientes là. Bien que ce soit génial pour github (plus d'argent), c'est moins pratique pour nous. Y at-il une solution à notre problème, peut-être avec des scripts exécutant une série de commandes git pour assembler correctement les branches et plus important encore refaire tous les commits dans le nouveau répertoire packages avec horodatage et author, donc il semble que les commits où fait-il tout au long de la place des sous-arbres? Ou est-ce que j'utilise juste le git log d'une manière incorrecte?

Answer 1

Vous pouvez rechercher gitslave (http://gitslave.sf.net) qui fournit la gestion de superprojet récursive CVSish dans le framework git. Il est beaucoup plus simple et plus facile d'utiliser ce git-submodules, mais il a quelques inconvénients (que vous ne remarquerez pas en venant de CVS). Contrairement à git-submodules, gitslave ne prend pas en charge votre référentiel, vous pouvez donc utiliser un mélange de commandes héritées et gitslave. Une utilisation peut toujours utiliser gitslave un autre peut toujours utiliser git pur, et un tiers peut utiliser un mélange d'avant en arrière. Une fois que vous avez configuré gitslave, vous pouvez créer une branche ou un tag sur tous les repos en une seule commande, et changer de branche, checkin, pousser ou faire ce que vous voulez.

Actuellement, il ne vous donnera probablement pas l'historique des fichiers que vous voulez sans travailler de votre côté, mais c'est quelque chose qui pourrait être ajouté (correctifs bienvenus :-).