Git-Fehler: Es gibt noch Protokolle unter

Ich versuche zu verwenden git fetch --all aber es gibt mir Fehler beim Abrufen eines bestimmten Repositorys.

Fehler: Es gibt immer noch Protokolle unter ‘.git/logs/refs/remotes/tpickel/RS’

und

! [new branch] RS -> tpickel/RS (lokale Referenz kann nicht aktualisiert werden)

Was ist schief gelaufen und wie kann man es beheben?

Anscheinend gab es früher eine tpickel/RS/foo (für irgendeinen Namen foo).

Ihr Git hat Informationen darüber aufgezeichnet, in .git/logs/refs/remotes/tpickel/RS/foo. Jetzt versucht Ihr Git, eine Datei mit dem Namen zu erstellen .git/logs/refs/remotes/tpickel/RSdas Informationen über die neue Verzweigung aufzeichnet tpickel/RS. Es kann dies nicht tun, weil es a gibt Verzeichnis, .git/logs/refs/remotes/tpickel/RS, Im weg. Das In-the-way-Verzeichnis enthält einige Dateien (foooder ein anderer Name, oben gibt es nichts, was den tatsächlichen Namen anzeigt), für das Ihr Git ein Reflog geführt hat tpickel/RS/foo.

Jetzt dieser Remote-Zweig tpickel/RS weg ist, muss Ihr Git beide entfernen refs/remotes/tpickel/RS/foo und seine Reflog-Datei. Im Idealfall, git fetch --prune tpickel erledige beides auf einmal für Sie, Vor versuchen, auch zu erstellen tpickel/RS und sein Reflog, das aufgrund des Verweilens fehlschlägt tpickel/RS/foo.

Wenn die --prune funktioniert, du bist fertig. Wenn nicht, müssen Sie hineingehen .git/logs/refs/remotes/tpickel/ und entweder alle entfernen RS und RS/* Einträge, oder benennen Sie sie um, um sie aus dem Weg zu räumen. (Wenn Sie diese trotz Fernbedienung speichern möchten tpickel Nachdem Sie den Zweig fallen gelassen haben, verschieben Sie sie, anstatt sie zu löschen, und lassen Sie es nicht zu git fetch --prune Lösche sie. Wahrscheinlich möchten Sie sie aber nicht speichern.)

Was --prune meint

Wenn du rennst git fetch remote (wie zum Beispiel git fetch tpickel), Git kontaktiert die benannte remote und erhält daraus eine Liste aller seiner Referenzen. Sie können diese Liste jederzeit selbst einsehen, indem Sie ausführen git ls-remote remote: Dies ruft den gleichen Start auf, stoppt dann aber nach dem Abrufen der Liste, anstatt mit dem Abrufen fortzufahren.

Angenommen, Ihr Git wird (wie es der normale Standardfall ist) angewiesen, alle seine Branch-Referenzen in Remote-Tracking-Branches zu kopieren. In diesem speziellen Beispiel würde das Kopieren bedeuten refs/heads/master zu refs/remotes/tpickel/master, zum Beispiel. Diese Art des Kopierens ist im Allgemeinen additiv: wenn entfernt tpickel hat Filialen master und develop heute und morgen fügen sie hinzu featurehaben Sie heute zwei Remote-Tracking-Zweige und fügen morgen einen neuen hinzu, wenn Sie ihre abrufen feature. Irgendwann dürfen sie es aber Löschen ein Zweig. Was ist, wenn sie entfernen feature wenn Sie noch verwenden refs/remotes/tpickel/feature?

Die Antwort von Git auf dieses Rätsel besteht darin, standardmäßig alle kopierten Referenzen für immer aufzubewahren. Wie Sie gerade gesehen haben, kann dies manchmal neuen Zweigen im Weg stehen, nachdem alte Zweige entfernt wurden, daher ist diese Lösung keineswegs perfekt. Was hinzufügen --prune Nehmen Sie die vollständige Liste, vergleichen Sie sie mit Ihrem Satz von Remote-Tracking-Zweigen und löschen aus Ihrem lokalen Repository jeden Remote-Tracking-Branch, der keinen entsprechenden Branch auf dem Remote hat. Das heißt, nur weil wir kopiert hatten ihr refs/heads/develop zu unser refs/remotes/tpickel/develop gestern, bedeutet nicht, dass wir sollten behalten refs/remotes/tpickel/develop heute, wenn ihr refs/heads/develop ist weg. Also, wenn Sie angeben --prunesucht Git nach solchen Vorkommen und löscht alle veralteten Remote-Tracking-Zweige.

Dieser Code gibt es schon eine Weile (seit 1.7 oder so, glaube ich). Git Version 1.8.5 hat zwei Konfigurationselemente hinzugefügt: fetch.prune und remote.remote.prune (z.B, remote.tpickel.prune). Wenn fetch.prune ist eingestellt auf true, git fetch immer Pflaumen; wenn die Konfiguration der spezifischen Fernbedienung auf eingestellt ist true, git fetch beschneidet diese bestimmte Fernbedienung.

(Der Code wurde in Version 2.0.0 von Git etwas verbessert, um potenziell mehrdeutige Zuordnungen zu handhaben. Dies deckt Fälle ab, in denen mehrere Upstream-Referenzen potenziell derselben Remote-Tracking-Referenz zugeordnet werden können. Bei normalen Setups passiert dies nie: Es kann nur vorkommen wenn du dir deine selbst ausdenkst fetch Einträge für eine benannte Fernbedienung.)

Das Ausführen von “rm -rf .git/logs” löste mein Problem.

Ich hatte ein ähnliches Problem beim Löschen .git/logs/refs/remotes/tpickel/RS/foo löste es

Dies hat mein Problem gelöst

git remote prune origin