Verschieben Sie mit Git LFS verfolgte Dateien unter normales Git

Lesezeit: 10 Minuten

Ich habe ein Projekt, in dem ich Videodateien mit Git LFS gespeichert habe. Jetzt hatte ich einige Komplikationen mit meinem Build-Server, der Git LFS noch nicht unterstützt. Da es sich um einen externen Dienst handelt, kann ich den Build-Prozess nicht wirklich beeinflussen und möchte daher die Dateien von unter Git LFS zurück auf “normales” Git verschieben. Ich habe es geschafft, die Dateitypen mit aufzuheben git lfs untrack '<file-type>' aber git lfs ls-files zeigt weiterhin eine Liste der zuvor hinzugefügten Dateien an.

Ich kann mir vorstellen, dass ich die Dateien entfernen, die Änderungen pushen und dann manuell wieder hinzufügen könnte, aber ist dies wirklich die empfohlene Vorgehensweise?

Verschieben Sie mit Git LFS verfolgte Dateien unter normales Git
mred

Ich bin erst kürzlich auf dieses Problem gestoßen, bei dem versehentlich Assets zu git-lfs in einem Zweig hinzugefügt wurden, die nicht hätten sein sollen. Meine Lösung war:

git lfs untrack '<file-type>'
git rm --cached '<file-type>'
git add '<file-type>'
git commit -m "restore '<file-type>' to git from lfs"

Das Ergebnis ist ein Umschreiben der git-lfs oid sha256-Zeiger mit dem Standard-Dateiinhalt.


(Edit 2019-03): Die akzeptierte Antwort wurde geändert, um eine einfache Lösung für einfachere Fälle bereitzustellen. Siehe auch die Bearbeitungen in der Antwort von VonC für alternative Lösungen, falls Sie einen komplexeren Fall zur Hand haben.

  • Mit .gitattributes richtig eingerichtet ist, um die gewünschten Dateien zu verfolgen, hat diese Lösung wunderbar funktioniert. Viel einfacher als einige der anderen veröffentlichten Lösungen.

    – Josh Rickert

    17. Mai ’17 um 21:15

  • Das hat wunderbar funktioniert. Sollte als die wahre Antwort aufgeführt werden.

    – Aditya

    20. Mai ’18 um 12:11

  • arbeitete für mich in ’18. Tipp für andere: ‘Dateityp’ war ‘**.jpg’

    – Oligofren

    28. Dezember ’18 um 17:19

  • @OlliNiskanen Obwohl es erfreulich ist, als akzeptierte Antwort markiert zu werden, halte ich es für wichtig anzumerken, dass dies zwar eine gute und einfache Lösung für die gestellte spezifische Frage ist, die Leser jedoch für komplexere Fälle die in den Bearbeitungen vorgeschlagenen Batching-Methoden konsultieren sollten tstephens619 und ttaylorr auf VonCs Antwort.

    – mred

    14. März ’19 um 13:22

  • @mred, Einverstanden. Ich habe eine Bearbeitung vorgeschlagen, die auf die vorherige akzeptierte Antwort verweist. Diese Antwort wurde ziemlich begraben und die Leute fanden sie hilfreich, daher denke ich, dass dies das Erste bleiben sollte, was Besucher sehen.

    – Olli Niskanen

    14. März ’19 um 17:34

Verschieben Sie mit Git LFS verfolgte Dateien unter normales Git
Tom Hebb

Ab Git 2.16 (veröffentlicht am 17. Januar 2018), können Sie dies ganz einfach mit dem --renormalize Flagge von git add:

git lfs untrack '<pattern>'
git add --renormalize .
git commit -m 'Restore file contents that were previously in LFS'

Von Git-Dokumentation:

–renormalize: Wenden Sie den “sauberen” Prozess frisch auf alle verfolgten Dateien an, um sie zwangsweise wieder zum Index hinzuzufügen. Dies ist nach dem Wechseln nützlich core.autocrlf Konfiguration oder die text -Attribut, um Dateien zu korrigieren, die mit falschen CRLF/LF-Zeilenenden hinzugefügt wurden. Diese Option impliziert -u.

Der Schlüsselteil hier ist “alle verfolgten Dateien”. Normalerweise werden Filter nur ausgeführt, wenn eine Git-Operation eine Datei im Arbeitsbaum ändert. Ändern der LFS-Whitelist in .gitattributes ist keine Git-Operation, und so endet der Index nach der Ausführung in einem inkonsistenten Zustand git lfs untrack. Betrieb git add --renormalize . weist Git an, Filter für jede Datei im Repository erneut auszuführen, wodurch sichergestellt wird, dass alle Dateien, die in LFS sein sollten, dies sind – und dass alle Dateien, die nicht sein sollten, es nicht sind.

  • Das Gute an dieser Methode ist, dass, wenn Sie aus der Vergangenheit oder einer anderen Filiale auschecken, das alte lfs-Zeug immer noch vorhanden ist. Aber in Zukunft verwendet es kein lfs mehr. Die eine Sache, die ich hinzufügen würde, ist, das lfs-Zeug jetzt aus .gitattributes zu entfernen (oder in meinem Fall die gesamte Datei zu löschen) und das auch einzuchecken.

    – David Casper

    27. Juni ’19 um 1:25

  • Es sollte beachtet werden, dass dies den Verlauf nicht ändert, was bedeutet, dass Sie beim Auschecken eines älteren Commit möglicherweise Zeiger auf LFS anstelle der tatsächlichen Dateien erhalten. Und wenn Sie das Repository inzwischen verschoben oder das LFS gelöscht haben, werden Sie diese alten großen Dateien auf diese Weise nicht zurückbekommen.

    – Thomas Tempelmann

    11. Mai ’20 um 14:03

  • Das Schlimme an dieser Methode ist, dass sie ALLE Dateien berührt und Sie mit einem massiven Commit von allem enden werden.

    – BigMiner

    2. November ’21 um 16:42

1641736236 827 Verschieben Sie mit Git LFS verfolgte Dateien unter normales Git
VonC

Ausgabe 641 erwähnt das gleiche Problem.

Ich habe versucht, Git LFS nicht mehr zu verwenden, habe aber keine Möglichkeit gefunden, meine zuvor verfolgten Zeigerdateien mit wiederherzustellen git lfs uninit, git lfs untrack, git rm… nachdem ich diese Dateien zurück verschoben habe, werden sie immer noch als von Git LFS verfolgt mit git lfs ls-files, wie kann ich das gesamte Git-LFS-Zeug aus meinem Repository entfernen?

Die Antwort war:

  1. Entfernen Sie alle filter.lfs.* git config-Einträge mit git lfs uninit.
  2. Löschen Sie alle Attribute, die den lfs-Filter verwenden in .gitattributes durch Laufen git lfs untrack für jeden Dateityp oder Löschen .gitattributes wenn LFS alles ist, wofür Sie es jemals verwendet haben.

Danach werden alle hinzugefügten Dateien direkt zu git.

Aber das war nicht so einfach:

Später lande ich in meinem Arbeitsverzeichnis mit LFS-Zeigerdateien und muss alle meine Bilder wiederherstellen .git/lfs den in diesen Zeigern gespeicherten sha1-Hash manuell verwenden.


Update März 2016, die Ausgabe 957 illustriert eine mögliche Lösung durch tstephens619:

Ich habe den gleichen Fehler gemacht, mehrere kleine Grafikformate in meine einzubinden git lfs Tracking-Liste.
Ich konnte diese Dateien wieder in git verschieben, indem ich Folgendes tat:

  • Erstellen Sie eine Liste aller Dateien, die derzeit verfolgt werden von git-lfs, Aussortieren *.gz und *.rpm (Ich möchte diese Erweiterungen weiterhin mit verfolgen git-lfs)

    git lfs ls-files | grep -vE ".gz|.rpm$" | cut -d ' ' -f 3 > ~/temp/lfs-files.txt
    
  • Stoppen Sie die Verfolgung der kleinen Grafikdateien

    git lfs untrack "*.tts"
    git lfs untrack "*.bfx"
    git lfs untrack "*.ttf"
    git lfs untrack "*.xcf"
    git lfs untrack "*.pkm"
    git lfs untrack "*.png"
    
  • Vorübergehend uninitiiert git-lfs

    git lfs uninit
    # Git LFS 2.x+
    git lfs uninstall
    
  • Verwenden Sie die Dateiliste, um jede Datei zu berühren:

    cat ~/temp/lfs-files.txt | xargs touch
    

git status zeigt jetzt jede Datei als geändert an

  • Fügen Sie die Änderungen zum Git-Index hinzu (ich habe dies über git gui)

  • Übernehmen Sie die Änderungen und initieren Sie git-lfs erneut

    git commit
    git lfs init
    

Der Betreuer ttaylorr fügt hinzu:

Eine Möglichkeit dies zu tun wäre:

for file in $FILES_TO_REVERT; do
  git lfs untrack "$file";
  git rm --cached "$file";
  git add --force "$file";
done

git commit -m "..."

Ich würde es vorziehen, Git LFS keinen Befehl zu dem oben genannten Effekt hinzuzufügen, da dies mit den Porzellanbefehlen von Git und Git LFS auf verschiedene Weise möglich ist

  • Vielen Dank, dass Sie das richtige Problem aus dem Projekt gefunden haben. Dennoch erfordert auch diese Lösung das manuelle Verschieben der Dateien. Scheint irgendwie seltsam, wenn der Workflow von Git zu Git LFS im Grunde ist git rm --cached <file> -> git add <file> -> git commit solange Sie das Tracking richtig eingerichtet haben.

    – Olli Niskanen

    28. Januar ’16 um 16:11

  • @Klipi Ich stimme zu: Es scheint, dass das Untrack-Szenario immer noch perfektionierbar ist.

    – VonC

    28. Januar ’16 um 16:17

  • @Klipi Guter Anruf. Ich werde es überwachen.

    – VonC

    28. Januar ’16 um 16:54

  • Meine Version von LFS (2.0.2) hat kein a uninit Befehl. Anstatt git lfs uninit musste ich benutzen git lfs uninstall.

    – endavid

    29. Apr. ’17 um 9:23

1641736236 622 Verschieben Sie mit Git LFS verfolgte Dateien unter normales Git
Joker

Ich hatte Probleme beim Ausführen von Schritten in Windows. Um alle von git lfs verfolgten Dateien zu entfernen und die Originaldatei wiederherzustellen, habe ich in git bash Folgendes getan:

  1. .gitattributes . entfernt

  2. git lfs ls-files | cut -d ' ' -f 3 > lfs-files.txt

  3. Führen Sie das folgende Snippet aus:

Ausschnitt:

while read file; do
  git lfs untrack "$file";
  git rm --cached "$file";
  git add --force "$file";
done <lfs-files.txt

1641736236 386 Verschieben Sie mit Git LFS verfolgte Dateien unter normales Git
Florian Winter

BEARBEITEN: Nach ein paar Jahren erfolgreicher Verwendung von GIT LFS und einer Reihe von Auf- und Abstimmen für diese Antwort gilt diese Warnung meiner Meinung nach immer noch: GIT LFS hat viele Mängel, z LFS, Leistungsprobleme beim (versehentlich) Hinzufügen vieler kleiner Dateien zu LFS unter Windows, eingeschränkte Unterstützung für mehrere Remotes und Remote-URL-Formate, Schwierigkeiten beim Entfernen von Dateien aus LFS, verschiedene Probleme, die beim Zusammenführen auftreten können usw. GIT LFS ist ein Fremdelement in GIT, die außerhalb des Revisionsbaums existiert. Ich möchte meine ursprüngliche Warnung jedoch wie folgt umformulieren:

  1. Legen Sie nur Dateien in GIT LFS ab, die Sie normalerweise in GIT einfügen würden (z. B. “Quelldateien”, die Sie besitzen und gelegentlich ändern).
  2. Legen Sie nur große Dateien in GIT LFS ab.
  3. Wenn Sie ein System zum Verwalten von binären Abhängigkeiten benötigen, sollten Sie stattdessen einen Paketmanager verwenden.
  4. Verwenden Sie Subversion nicht als Ersatz für GIT LFS. Es ist schlimmer.
  5. Seien Sie darauf vorbereitet, Ihr Arbeitsverzeichnis durcheinander zu bringen. Stellen Sie sicher, dass Sie wichtige Änderungen sichern (pushen), bevor Sie größere Änderungen an LFS vornehmen.
  6. Beim Zusammenführen immer zusammenführen .gitattributes Erste.

EDIT: Hier ist meine ursprüngliche Antwort:

Es ist schwierig, etwas aus GIT LFS zu entfernen, und obwohl die hier vorgestellten Lösungen (mit Modifikationen) funktionieren können, erfordern sie viel Aufwand und können Nebenwirkungen auf Ihr Repository haben.

Wenn Sie hier angekommen sind, ist es an der Zeit, sich zu fragen, ob Sie Ihre großen Dateien mit GIF LFS verwalten möchten und ob GIT selbst (das bei der Verwaltung großer Dateien von Natur aus schlecht ist, da es ein verteiltes Versionskontrollsystem ist) eine gute Wahl war.

Wenn Sie viele große Dateien haben und eine einzelne Organisation an Ihrem Projekt arbeitet, kann etwas wie Subversion für Sie besser funktionieren.

  • @ericfrazer Jeder einzelne Besuch dieser Frage beweist meinen Standpunkt, da das Entfernen von Dateien aus LFS nach der offiziellen Dokumentation von GIT LFS ein Kinderspiel sein sollte. Außer, ist es nicht, weil es nicht funktioniert. Die Leute haben Schwierigkeiten, weil a) es schwierig ist, die hinzuzufügenden Dateien fein abzustimmen, und b) das Hinzufügen vieler kleiner Dateien unter Windows zu Leistungsproblemen führt, da GIT LFS als Unterprozess ausgeführt wird und das Starten von Unterprozessen ohne das teuer ist Gabel(). Fazit: Verwenden Sie für Ihre eigene geistige Gesundheit kein LFS, bevor dies alles behoben ist. Was seit Jahren nicht mehr passiert ist…

    – Florian Winter

    18. Dez. ’18 um 11:53

  • Diese Antwort ist eher ein Gesichtspunkt als eine Antwort, aber als Frage steht für die Verwendung von GIT für große Binärdateien, Dies sieht eher aus wie ein Warnung, ich stimme zu nicht löschen diese Antwort.

    – F. Hauri

    20. September ’21 um 8:31

  • @ericfrazer Jeder einzelne Besuch dieser Frage beweist meinen Standpunkt, da das Entfernen von Dateien aus LFS nach der offiziellen Dokumentation von GIT LFS ein Kinderspiel sein sollte. Außer, ist es nicht, weil es nicht funktioniert. Die Leute haben Schwierigkeiten, weil a) es schwierig ist, die hinzuzufügenden Dateien fein abzustimmen, und b) das Hinzufügen vieler kleiner Dateien unter Windows zu Leistungsproblemen führt, da GIT LFS als Unterprozess ausgeführt wird und das Starten von Unterprozessen ohne das teuer ist Gabel(). Fazit: Verwenden Sie für Ihre eigene geistige Gesundheit kein LFS, bevor dies alles behoben ist. Was seit Jahren nicht mehr passiert ist…

    – Florian Winter

    18. Dez. ’18 um 11:53

  • Diese Antwort ist eher ein Gesichtspunkt als eine Antwort, aber als Frage steht für die Verwendung von GIT für große Binärdateien, Dies sieht eher aus wie ein Warnung, ich stimme zu nicht löschen diese Antwort.

    – F. Hauri

    20. September ’21 um 8:31

.

215110cookie-checkVerschieben Sie mit Git LFS verfolgte Dateien unter normales Git

This website is using cookies to improve the user-friendliness. You agree by using the website further.

Privacy policy