Il s'avère que la réponse est beaucoup plus simple si vous essayez simplement de coller deux référentiels ensemble et de faire en sorte que ce soit comme ça tout au long plutôt que de gérer une dépendance externe. Il vous suffit d'ajouter des télécommandes à vos anciens référentiels, de les fusionner avec votre nouveau maître, de déplacer les fichiers et dossiers dans un sous-répertoire, de valider le déplacement et de répéter pour tous les référentiels supplémentaires. Les sous-modules, les fusions de sous-arbres et les rebases sophistiqués sont destinés à résoudre un problème légèrement différent et ne conviennent pas à ce que j'essayais de faire.
Voici un exemple de script Powershell pour coller deux référentiels ensemble:
# Assume the current directory is where we want the new repository to be created
# Create the new repository
git init
# Before we do a merge, we have to have an initial commit, so we'll make a dummy commit
git commit --allow-empty -m "Initial dummy commit"
# Add a remote for and fetch the old repo
git remote add -f old_a <OldA repo URL>
# Merge the files from old_a/master into new/master
git merge old_a/master --allow-unrelated-histories
# Move the old_a repo files and folders into a subdirectory so they don't collide with the other repo coming later
mkdir old_a
dir -exclude old_a | %{git mv $_.Name old_a}
# Commit the move
git commit -m "Move old_a files into subdir"
# Do the same thing for old_b
git remote add -f old_b <OldB repo URL>
git merge old_b/master --allow-unrelated-histories
mkdir old_b
dir –exclude old_a,old_b | %{git mv $_.Name old_b}
git commit -m "Move old_b files into subdir"
Évidemment, vous pouvez plutôt fusionner old_b dans old_a (qui devient le nouveau référentiel combiné) si vous préférez le faire - modifier le script en fonction.
Si vous souhaitez également ajouter des branches de fonctionnalités en cours, utilisez ceci:
# Bring over a feature branch from one of the old repos
git checkout -b feature-in-progress
git merge -s recursive -Xsubtree=old_a old_a/feature-in-progress
C'est la seule partie non évidente du processus - ce n'est pas une fusion de sous-arborescence, mais plutôt un argument pour la fusion récursive normale qui indique à Git que nous avons renommé la cible et qui aide Git à tout aligner correctement.
J'ai écrit une explication un peu plus détaillée ici .
