A --tree-filter arbeitet nicht an/mit dem Index. Stattdessen kopiert es jedes Commit in ein temporäres Verzeichnis, das als Arbeitsbaum verwendet wird, führt den Befehl in diesem temporären Verzeichnis aus und macht das neue Commit aus den verbleibenden und/oder neuen Dateien im temporären Verzeichnis. Änderungen, die Sie während dieses Vorgangs am Index selbst vornehmen, werden effektiv ignoriert.
Das bedeutet, dass Sie aus dem Arbeitsbaum genau die Dateien entfernen müssen, die Ihr neues .gitignore verhindert, hinzugefügt zu werden. Sie könnten dies manuell mit git rm --cached in einem --index-filter tun, die viel schneller wäre, aber wenn Sie git die Arbeit für Sie in einem --tree-filter tun wollen, können Sie den gleichen Trick git selbst verwenden (siehe Fußnote): verwenden git clean (mit -x), um das temporäre Verzeichnis zu bereinigen.
Das ist nicht ganz richtig: filter-branch ‚s --tree-filter Code git read-tree verwendet den Index vor (Wieder-) bevölkern das temporäre Verzeichnis (die wiederum zu bevölkern, bedeutet es einige Arbeit zu tun hat zu reinigen, die temporäres Verzeichnis von früheren Commits, für die es git clean verwendet). Dann, nach eval Ihren Filter, verwendet es den Index erneut, um zu überprüfen, was im temporären Verzeichnis getan wurde. Wenn Sie git rm -r --cached . und dann git add . vergleichen, vergleicht es den resultierenden Index, der nicht mehr Ihre ignorierten Dateien enthält, mit dem Arbeitsbaum und ... fügt Ihre ignorierten Dateien hinzu. Argh!