Verweise auf ein Submodul im übergeordneten Repository aktualisieren, nachdem das GIT-Protokoll des Submoduls neu geschrieben wurde

Question

Im Folgenden wird das Skript beschrieben, mit dem ich den Verlauf eines Submoduls neu schreibe, auf das in mehreren übergeordneten Repositorys verwiesen wird. Dies läuft in Git bash in einer Windows-Umgebung.

#!/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 

Ich muß irgendwie mit dem neu geschaffenen SHA s dem SHA s des alten Commits auf der Karte, so dass ich die gleiche Referenz in den übergeordneten Repositories aktualisieren kann. Gibt es einen Weg, es zu tun? Ich habe mir Repository with submodules after rewriting history of submodule angesehen, aber es hilft nicht wirklich, da ich die Original-Refs aktualisiere, um sicherzustellen, dass die Dateien, die ich entferne, nicht zufällig neu gepackt werden. Ich bin relativ neu in der Verwendung von Git, so dass jede Anleitung wirklich geschätzt werden würde.

bearbeiten:

die Schritte in den Kommentaren Abschnitt der akzeptierte Antwort (von @torek) erwähnt Nach arbeitete für mich.

Answer 1

Es gibt keine gute Möglichkeit, dies zu tun (zumindest mit git filter-branch und vorhandenen Git-Tools - die BFG verlässt die gewünschte Map-Datei herum, aber erfordert immer noch etwas zu konstruieren).

Wenn git filter-branch Kopien festlegt, legt es den Hash eines neuen Commits in eine "Map-Datei" (die alte und die neue ID zusammen) - eigentlich ein Verzeichnis in der vorhandenen Implementierung, obwohl dies in großen Filtern sehr schlecht funktioniert eines Tages geändert werden), so dass es möglich ist, vom Original-Commit-Hash zum Rewited-Commit-Hash zu konvertieren. Dies ist, wie sieht es die map Funktion, dass the git filter-branch documentation hier bezieht:

A Karte Funktion steht zur Verfügung, die ein „Original-SHA1-id“ Argument nimmt und gibt eine „neu geschrieben SHA1-ID“, wenn das bereits begangen hat umgeschrieben, und "Original sha1 id" sonst; Die Karte Funktion kann mehrere IDs in separaten Zeilen zurückgeben, wenn Ihr Commit-Filter mehrere Commits ausgibt. Leider

, wenn git filter-branch Oberflächen und reinigt es entfernt die Zuordnungstabelle, anstatt es in eine nützliche Datenbank drehen. Wenn Sie die Datenbank mit den Zuordnungen hätten, könnten Sie diese mit beliebigen externen Elementen verwenden ("gitlink" -Einträge in anderen Repositories, Test-Frameworks oder an jedem anderen Ort, an dem Sie sie gespeichert haben könnten). Ohne die Karte gibt es keinen guten Weg, damit umzugehen. Das Superprojekt sagt z. B. "Verwenden Sie Commit 1234567", aber dieses Commit existiert nicht mehr in dem umgeschriebenen Submodul-Repository. Die ID des neuen Commits wäre in der Karte, aber es gibt keine Karte.