Il s'avère que la réponse est beaucoup plus simple si vous essayez simplement de la colle à deux référentiels ensemble et le faire paraître comme il a été de cette façon tout au long plutôt que de gérer une dépendance externe. Vous avez simplement besoin d'ajouter des télécommandes à votre ancienne repos, de les fusionner pour votre nouveau maître, de déplacer les fichiers et les dossiers dans un sous-répertoire, commettre le déplacer, et répétez l'opération pour tous les autres titres. Submodules, sous-arborescence de la fusion, et de la fantaisie rebases sont destinés à résoudre un problème un peu différent et ne sont pas adaptés pour 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
dir > deleteme.txt
git add .
git commit -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
# Clean up our dummy file because we don't need it any more
git rm .\deleteme.txt
git commit -m "Clean up initial file"
# 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
mkdir old_b
dir –exclude old_a,old_b | %{git mv $_.Name old_b}
git commit -m "Move old_b files into subdir"
Bien évidemment, on pourrait à la place de fusion old_b en old_a (qui devient le nouveau combiné repo) si vous préférez le faire – de modifier le script pour l'adapter.
Si vous voulez apporter plus de en progrès branches, procédez comme 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 le seul non-évidente dans le cadre de la procédure, ce n'est pas un sous-arbre de fusion, mais plutôt d'un argument à la normale récursive de fusion qui indique à Git que nous l'avons renommé la cible et qui permet de Git ligne tout en place correctement.
J'ai écrit un peu plus d'explications détaillées ici.
