Sie wirklich alle Varianten eines Dateinamens entfernt haben, wenn ein Blob im Laufe seines Lebens über seinen Namen verschoben wurde. git log --name-only --follow --all -- filename kann Ihnen helfen, Umbenennungen zu finden.

Sie wirklich alle Referenzen gefiltert haben: Verwenden Sie --tag-name-filter cat -- --all beim Aufrufen von git-filter-branch.

Klonen Sie es mit git clone file:///pfad/zum/repo. Der Klon wird die entfernten Objekte nicht enthalten. Siehe git-clone[1]. (Beachten Sie, dass das Klonen mit einem einfachen Pfad alles hartlinkt!)

Entfernen Sie die ursprünglichen Referenzen, die von git-filter-branch gesichert wurden: z. B. git for-each-ref --format="%(refname)" refs/original/ | xargs -n 1 git update-ref -d.

Verfallen Sie alle Reflogs mit git reflog expire --expire=now --all.

Sammeln Sie alle nicht referenzierten Objekte mit git gc --prune=now (oder wenn Ihr git-gc nicht neu genug ist, um Argumente für --prune zu unterstützen, verwenden Sie stattdessen git repack -ad; git prune).

Beim Bearbeiten von Dateien prüft git-filter-branch designbedingt jeden einzelnen Commit aus, wie er im ursprünglichen Repository existierte. Wenn Ihr Repository 10^5 Dateien und 10^5 Commits hat, aber jeder Commit nur fünf Dateien modifiziert, dann zwingt git-filter-branch Sie zu 10^10 Modifikationen, obwohl es (höchstens) 5*10^5 eindeutige Blobs gibt.

Wenn Sie versuchen zu schummeln und git-filter-branch nur an Dateien arbeiten zu lassen, die in einem Commit modifiziert wurden, dann passieren zwei Dinge:

Selbst wenn Sie keine Dateien bearbeiten müssen, sondern nur z. B. einige umbenennen oder entfernen möchten und somit das Auschecken jeder Datei vermeiden können (d. h. Sie können --index-filter verwenden), übergeben Sie immer noch Shell-Schnipsel für Ihre Filter. Das bedeutet, dass Sie für jeden Commit ein vorbereitetes Git-Repository haben müssen, in dem diese Filter ausgeführt werden können. Das ist eine erhebliche Einrichtung.

Darüber hinaus werden pro Commit mehrere zusätzliche Dateien von git-filter-branch erstellt oder aktualisiert. Einige davon dienen der Unterstützung der von git-filter-branch bereitgestellten Komfortfunktionen (wie map()), während andere der Verfolgung des internen Zustands dienen (aber auch von Benutzerfiltern hätten zugegriffen werden können; einer der Regressionstests von git-filter-branch tut dies). Dies läuft im Wesentlichen darauf hinaus, das Dateisystem als IPC-Mechanismus zwischen git-filter-branch und den vom Benutzer bereitgestellten Filtern zu verwenden. Festplatten sind tendenziell ein langsamer IPC-Mechanismus, und das Schreiben dieser Dateien stellt auch eine erzwungene Synchronisationsstelle zwischen separaten Prozessen dar, auf die wir bei jedem Commit stoßen.

Die vom Benutzer bereitgestellten Shell-Befehle beinhalten wahrscheinlich eine Pipeline von Befehlen, was zur Erstellung vieler Prozesse pro Commit führt. Das Erstellen und Ausführen eines weiteren Prozesses dauert je nach Betriebssystem stark variierend, ist aber auf jeder Plattform sehr langsam im Vergleich zum Aufruf einer Funktion.

git-filter-branch selbst ist in Shell geschrieben, was eher langsam ist. Dies ist das einzige Leistungsproblem, das abwärtskompatibel behoben werden könnte, aber im Vergleich zu den oben genannten Problemen, die dem Design von git-filter-branch innewohnen, ist die Sprache des Tools selbst ein relativ geringfügiges Problem.

Jemand kann einen Satz von "funktionierenden und getesteten Filtern" haben, die er dokumentiert oder einem Kollegen zur Verfügung stellt, der sie dann auf einem anderen Betriebssystem ausführt, wo dieselben Befehle nicht funktionieren/getestet werden (einige Beispiele in der git-filter-branch-Manpage sind ebenfalls davon betroffen). Unterschiede zwischen der Benutzerumgebung von BSD und GNU können wirklich schmerzhaft sein. Wenn man Glück hat, werden Fehlermeldungen ausgegeben. Aber genauso gut tun die Befehle entweder nicht die angeforderte Filterung oder beschädigen stillschweigend, indem sie unerwünschte Änderungen vornehmen. Die unerwünschte Änderung kann nur wenige Commits betreffen, daher ist sie auch nicht unbedingt offensichtlich. (Die Tatsache, dass Probleme nicht unbedingt offensichtlich sind, bedeutet, dass sie wahrscheinlich unbemerkt bleiben, bis der umgeschriebene Verlauf eine ganze Weile verwendet wird, an dem Punkt ist es wirklich schwer, einen weiteren Flaggen-Tag für eine weitere Umschreibung zu rechtfertigen.)

Dateinamen mit Leerzeichen werden oft von Shell-Snippets falsch behandelt, da sie Probleme für Shell-Pipelines verursachen. Nicht jeder ist mit find -print0, xargs -0, git-ls-files -z usw. vertraut. Selbst Leute, die damit vertraut sind, können davon ausgehen, dass solche Flags nicht relevant sind, weil jemand anderes solche Dateien in seinem Repository umbenannt hat, bevor die Person, die filtert, dem Projekt beigetreten ist. Und oft tun selbst diejenigen, die mit der Handhabung von Argumenten mit Leerzeichen vertraut sind, dies nur, weil sie nicht im Gedanken sind, alles zu bedenken, was schiefgehen könnte.

Nicht-ASCII-Dateinamen können stillschweigend entfernt werden, obwohl sie sich in einem gewünschten Verzeichnis befinden. Das Beibehalten nur gewünschter Pfade wird oft mit Pipelines wie git ls-files | grep -v ^WANTED_DIR/ | xargs git rm durchgeführt. ls-files maskiert Dateinamen nur, wenn nötig, daher bemerken die Leute möglicherweise nicht, dass eine der Dateien nicht mit dem Regex übereinstimmt (zumindest nicht, bis es viel zu spät ist). Ja, jemand, der von core.quotePath weiß, kann dies vermeiden (es sei denn, er hat andere Sonderzeichen wie \t, \n oder "), und Leute, die ls-files -z mit etwas anderem als grep verwenden, können dies vermeiden, aber das bedeutet nicht, dass sie es tun werden.

Ähnlich kann man beim Verschieben von Dateien feststellen, dass Dateinamen mit Nicht-ASCII- oder Sonderzeichen in einem anderen Verzeichnis landen, das ein doppeltes Anführungszeichen enthält. (Dies ist technisch gesehen dasselbe Problem wie oben mit Anführungszeichen, aber vielleicht eine interessante andere Art, wie es sich manifestiert hat und ein Problem darstellt.)

Es ist viel zu einfach, alte und neue Verläufe versehentlich zu vermischen. Das ist mit jedem Werkzeug immer noch möglich, aber git-filter-branch lädt geradezu dazu ein. Wenn man Glück hat, ist der einzige Nachteil, dass Benutzer frustriert sind, weil sie nicht wissen, wie sie ihr Repository verkleinern und die alten Sachen entfernen können. Wenn man Pech hat, vermischt man alte und neue Verläufe und hat am Ende mehrere "Kopien" jedes Commits, von denen einige unerwünschte oder sensible Dateien enthalten und andere nicht. Dies geschieht auf vielfältige Weise:

Annotierte Tags können versehentlich in Lightweight-Tags umgewandelt werden, entweder aus einem von zwei Gründen:

Alle Commit-Nachrichten, die eine Kodierung angeben, werden durch die Umschreibung beschädigt; git-filter-branch ignoriert die Kodierung, nimmt die ursprünglichen Bytes und übergibt sie an commit-tree, ohne ihm die korrekte Kodierung mitzuteilen. (Dies geschieht, unabhängig davon, ob --msg-filter verwendet wird oder nicht.)

Commit-Nachrichten (auch wenn sie alle UTF-8 sind) werden standardmäßig beschädigt, da sie nicht aktualisiert werden – alle Verweise auf andere Commit-Hashes in Commit-Nachrichten beziehen sich nun auf nicht mehr existierende Commits.

Es gibt keine Einrichtungen, die den Benutzern helfen, unerwünschte Artefakte zu finden, die sie löschen sollten, was bedeutet, dass sie eher unvollständige oder teilweise Bereinigungen haben, die manchmal zu Verwirrung führen und Leute Zeit damit verschwenden, Dinge zu verstehen. (Zum Beispiel neigen Leute dazu, nur nach großen Dateien zu suchen, anstatt nach großen Verzeichnissen oder Erweiterungen, und nachdem sie dies getan haben, bemerken Leute, die später das neue Repository verwenden und den Verlauf durchgehen, ein Build-Artefaktverzeichnis, das einige Dateien, aber nicht andere hat, oder einen Cache von Abhängigkeiten (node_modules oder ähnlich), der nie funktionsfähig gewesen sein kann, da ihm einige Dateien fehlen.)

Wenn --prune-empty nicht angegeben ist, kann der Filterprozess Scharen verwirrender leerer Commits erzeugen.

Wenn --prune-empty angegeben ist, werden auch absichtlich platzierte leere Commits aus der Zeit vor dem Filtervorgang bereinigt, anstatt nur Commits zu bereinigen, die aufgrund von Filterregeln leer geworden sind.

Wenn --prune-empty angegeben ist, werden manchmal leere Commits übersehen und trotzdem belassen (ein eher seltener Fehler, aber es kommt vor...)

Ein geringfügiges Problem, aber Benutzer, die das Ziel haben, alle Namen und E-Mails in einem Repository zu aktualisieren, können zu --env-filter geführt werden, der nur Autoren und Committer aktualisiert und Tagger übersieht.

Wenn der Benutzer einen --tag-name-filter angibt, der mehrere Tags auf denselben Namen abbildet, wird keine Warnung oder kein Fehler ausgegeben; git-filter-branch überschreibt einfach jeden Tag in einer undokumentierten, vordefinierten Reihenfolge, was am Ende zu nur einem Tag führt. (Ein Regressionstest von git-filter-branch erfordert dieses überraschende Verhalten.)

Das Erstellen des korrekten Shell-Snippets zur Durchführung der gewünschten Filterung ist manchmal schwierig, es sei denn, Sie nehmen nur eine triviale Änderung vor, wie z. B. das Löschen einiger Dateien. Leider lernen die Leute oft, ob das Snippet richtig oder falsch ist, indem sie es ausprobieren, aber die Richtigkeit oder Falschheit kann je nach besonderen Umständen variieren (Leerzeichen in Dateinamen, Nicht-ASCII-Dateinamen, seltsame Autorennamen oder E-Mails, ungültige Zeitzonen, Vorhandensein von Grafts oder Ersetzungsobjekten usw.), was bedeutet, dass sie möglicherweise lange warten, einen Fehler erhalten und dann neu starten müssen. Die Leistung von git-filter-branch ist so schlecht, dass dieser Zyklus schmerzhaft ist, was die Zeit für sorgfältige Überprüfung reduziert (ganz zu schweigen davon, was dies mit der Geduld der Person, die die Umschreibung durchführt, macht, selbst wenn sie technisch mehr Zeit zur Verfügung hat). Dieses Problem wird zusätzlich dadurch verschärft, dass Fehler von defekten Filtern möglicherweise erst lange danach angezeigt werden und/oder in einem Meer von Ausgabe untergehen. Noch schlimmer ist, dass defekte Filter oft nur zu stillschweigenden falschen Umschreibungen führen.

Zu allem Überfluss, selbst wenn Benutzer schließlich funktionierende Befehle finden, möchten sie diese natürlich teilen. Aber sie sind sich möglicherweise nicht bewusst, dass ihr Repository nicht einige Sonderfälle hatte, die jemand anderes hat. Wenn also jemand mit einem anderen Repository dieselben Befehle ausführt, trifft er auf die oben genannten Probleme. Oder der Benutzer führt einfach Befehle aus, die wirklich für Sonderfälle geprüft wurden, aber er führt sie auf einem anderen Betriebssystem aus, wo sie nicht funktionieren, wie oben erwähnt.