Mise à jour des références à un sous-module dans le référentiel parent après que l'historique git du sous-module a été réécrit

Question

Voici le script que j'utilise pour réécrire l'historique d'un sous-module référencé dans plusieurs référentiels parents. Cela fonctionne dans Git bash dans un environnement Windows.

#!/bin/bash 

cd submodule_repo 

git filter-branch --index-filter 'git rm -q --cached --ignore-unmatch files_to_remove' \--tag-name-filter cat -- --all 

git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d 

git reflog expire --expire=now --all 
git gc --prune=now 

J'ai besoin de la carte en quelque sorte les SHA s des anciens commits ceux nouvellement créés SHA s, afin que je puisse mettre à jour la même référence dans les dépôts de parents. Y a-t-il un moyen de le faire? J'ai regardé Repository with submodules after rewriting history of submodule, mais cela n'aide pas vraiment car je suis en train de mettre à jour les références d'origine pour m'assurer que les fichiers que je supprime ne sont pas reconditionnés par hasard. Je suis relativement nouveau à l'utilisation de git donc toute orientation serait vraiment appréciée.

Modifier:

En suivant les étapes mentionnées dans les commentaires de la section réponse acceptée (par @torek) a travaillé pour moi.

Answer 1

Il n'y a aucun moyen de le faire (au moins avec git filter-branch et les outils Git existants-le BFG laisse le fichier de carte désiré autour, mais nécessite encore de construire quelque chose). Lorsque git filter-branch copies valide, il place chaque nouveau hachage de commit dans un "fichier map" (en associant l'ancien et le nouveau ID - en réalité un répertoire dans l'implémentation existante, bien que cela fonctionne très mal dans les grands filtres, donc il peut un jour être modifié), de sorte qu'il est possible de convertir du hachage original-commit en un hachage rewritten-commit. Voici comment cela fournit la fonction map que the git filter-branch documentation fait référence ici:

Une fonction carte est disponible qui prend un argument « id SHA1 d'origine » et émet un « réécrite id SHA1 » si l'engagement a déjà été réécrit, et "original sha1 id" sinon; la fonction map peut renvoyer plusieurs identifiants sur des lignes distinctes si votre filtre de validation a émis plusieurs validations.

Malheureusement, lorsque git filter-branch finitions et nettoie, il supprime la table de correspondance, plutôt que de le transformer en une base de données utile. Si vous avez la base de données avec les mappages, vous pouvez l'utiliser avec des éléments externes (entrées "gitlink" dans d'autres référentiels, cadres de test ou tout autre endroit où vous pourriez les avoir sauvegardés). Sans la carte, il n'y a pas de bonne façon de gérer cela. Le superprojet indique, par exemple, "use commit 1234567" mais cette validation n'existe plus dans le référentiel de sous-module réécrit. L'ID du nouveau commit serait sur la carte, mais il n'y a pas de carte.