git gc / git gui: Das Aufheben der Verknüpfung der Datei <interner Paketdateiname> ist fehlgeschlagen
Laufende Version1.9.4.msysgit.0 vongitIch erhalte die genannten Fehler fast jedes Mal, wenn ich rennegit gc auf der Kommandozeile oder übergit gui wenn es mich auffordert, "lose Gegenstände zu komprimieren":
Counting objects: 1110956, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (269562/269562), done.
Writing objects: 100% (1110956/1110956), done.
Total 1110956 (delta 636114), reused 1110956 (delta 636114)
Unlink of file '.git/objects/pack/pack-207f1feb5376880778637c ... 8371cea62.pack'
failed. Should I try again? (y/n) n
Checking connectivity: 1110956, done.
Die einzige Lösung scheint das Schlagen zu seinn für jede der gesperrten Dateien - wie von vorgeschlagendieser Thread:
Kurze Antwort: Drücke 'n', um all diese zu durchlaufen, und führe dann manuell "git gc" aus.
Der Thread deutet auch an, dass ...
Das Problem ist, dass die Dateien von einer übergeordneten git.exe derjenigen, die versucht, die gc auszuführen, geöffnet gehalten werden.
... was beim Blick auf den Prozessbaum durchaus plausibel ist:
Meine Frage ist, gibt es etwas, was ich tun kann, um dies zu verhindern? Es wird wirklich ärgerlich, das mehrmals am Tag machen zu müssen ... Und warum passiert das? Ist es ein git / w32-only Bug?
Update 1: Zur Verdeutlichung - nach dem Schlagenn mehrmals wie beschrieben,git gc beendet wird und das lokale Repository "sauber" ist, d. h. erneut ausgeführt wirdgit gc verursacht keine Probleme mehr mit der Dateisperre -Dies ist aber nur für einige Zeit. Nach einigen Arbeiten am Repository - manchmal nach Minuten, manchmal nach Stunden - ist das Repository wieder "schmutzig" und die beschriebenen Probleme treten auf. Laufengit gc von innengit-bash Anstatt voncmd wie vorgeschlagen vonjsexpert hilft nicht. Er schlug ferner vor, dass anderegit Software hält möglicherweise die fraglichen Sperren. Ich bin skeptisch, nicht zuletzt wegen des Kommentars im oben verlinkten Thread - ich denke, ein Elternteilgit Prozess hält die Schlösser - aber ich muss immer noch diese Behauptung überprüfen.
Update 2: Stellt sich heraus, dassjsexpert war die ganze Zeit richtig - zumindest in meinem Fall war es in der Tat die IDE, die diese Dateien sperrte ... Also ist es ein Problem derEGit Team Provider für Eclipse und nichtgit selbst.
Update 3: Um gesperrte Dateien zu finden, können Sie beispielsweise eines der folgenden kostenlosen Tools verwenden:
Process Explorer (inzwischen ein Microsoft-Angebot)Prozess Hacker (Inzwischen wurde Process Explorer in meinem Toolset ersetzt.)Verwenden Sie in beiden FällenSTRGF um den "Find Handle" -Dialog aufzurufen.