Wie oft sollten Sie git-gc verwenden?

Wie oft sollten Sie git-gc verwenden?

Der Handbuchseite sagt einfach:

Benutzern wird empfohlen, diese Aufgabe regelmäßig in jedem Repository auszuführen, um eine gute Speicherplatznutzung und eine gute Betriebsleistung aufrechtzuerhalten.

Gibt es einige Befehle, um einige Objektzahlen zu erhalten, um herauszufinden, ob es Zeit für gc ist?

Es hängt hauptsächlich davon ab, wie stark das Repository verwendet wird. Mit einem Benutzer, der einmal am Tag eincheckt, und einer Verzweigungs-/Merge-/usw.-Operation einmal pro Woche, müssen Sie ihn wahrscheinlich nicht öfter als einmal im Jahr ausführen.

Da mehrere Dutzend Entwickler an mehreren Dutzend Projekten arbeiten, die jeweils 2-3 Mal am Tag einchecken, möchten Sie es vielleicht jede Nacht ausführen.

Es schadet jedoch nicht, es öfter als nötig auszuführen.

Was ich tun würde, ist, es jetzt auszuführen, dann in einer Woche eine Messung der Festplattenauslastung vorzunehmen, es erneut auszuführen und die Festplattenauslastung erneut zu messen. Wenn es um 5% an Größe abfällt, dann lass es einmal pro Woche laufen. Wenn es mehr abfällt, dann lass es häufiger laufen. Wenn es weniger abfällt, dann lass es weniger häufig laufen.

Beachten Sie, dass der Nachteil des Garbage-Collection Ihres Repositorys darin besteht, dass der Garbage-Collection gesammelt wird. Wie wir alle als Computerbenutzer wissen, könnten sich Dateien, die wir derzeit als Müll betrachten, drei Tage später als sehr wertvoll erweisen. Die Tatsache, dass Git den größten Teil seiner Ablagerungen herumträgt, hat mir mehrmals den Speck gerettet – indem ich alle baumelnden Commits durchsucht habe, habe ich viel Arbeit zurückgewonnen, die ich versehentlich in Dosen gespeichert hatte.

Seien Sie also nicht zu sehr ein ordentlicher Freak in Ihren privaten Klonen. Es gibt wenig Bedarf dafür.

OTOH, der Wert der Datenwiederherstellung ist fraglich für Repos, die hauptsächlich als Remotes verwendet werden, z. der Ort, an den alle Entwickler drängen und/oder von dem sie gezogen werden. Da kann es sinnvoll sein, häufig einen GC-Lauf und ein Umpacken anzustoßen.

Neuere Versionen von git führen gc bei Bedarf automatisch aus, sodass Sie nichts tun müssen. Siehe den Abschnitt „Optionen“ von man git-gc(1): “Einige Git-Befehle führen git gc –auto aus, nachdem Operationen durchgeführt wurden, die viele lose Objekte erzeugen könnten.”

Wenn Sie verwenden Git-Guies sagt Ihnen, wann Sie sich Sorgen machen sollten:

This repository currently has approximately 1500 loose objects.

Der folgende Befehl bringt eine ähnliche Nummer:

$ git count-objects

Außer, aus seiner Quellegit-gui wird die Berechnungen selbst durchführen und tatsächlich etwas zählen .git/objects Ordner und bringt wahrscheinlich eine Annäherung (ich weiß es nicht tcl um das richtig zu lesen!).

Auf jeden Fall es scheint um die Warnung basierend auf einer beliebigen Zahl zu geben um herum 300 lose Gegenstände.

Legen Sie es in einem Cron-Job ab, der jede Nacht (nachmittags?) ausgeführt wird, wenn Sie schlafen.

Mit der neuen Einstellung (Git 2.0 Q2 2014) können Sie dies ohne Unterbrechung tun gc.autodetach.

Sehen Commit 4c4ac4d und 9f673f9 begehen (Nguyễn Thái Ngọc Duy, alias pclouds):

gc --auto dauert seine Zeit und kann den Benutzer vorübergehend blockieren (aber nicht weniger ärgerlich).
Lassen Sie es auf Systemen, die es unterstützen, im Hintergrund laufen.
Das einzige, was beim Laufen im Hintergrund verloren geht, sind Ausdrucke. Aber gc output ist nicht wirklich interessant.
Sie können es im Vordergrund behalten, indem Sie es ändern gc.autodetach.

Seit dieser Version 2.0 gab es jedoch einen Fehler: git 2.7 (Q4 2015) wird dafür sorgen die Fehlermeldung nicht verlieren.
Sehen Commit 329e6e8 (19.09.2015) von Nguyễn Thái Ngọc Duy (pclouds).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in 076c827 begehen15. Okt. 2015)}

gc: Protokoll von daemonized speichern gc --auto und beim nächsten Mal ausdrucken

Während 9f673f9 begehen (gc: Konfigurationsoption zum Ausführen --auto im Hintergrund – 2014-02-08) hilft, einige Beschwerden über “gc --auto‘ Das Terminal in Beschlag zu nehmen, schafft eine weitere Reihe von Problemen.

Das Neueste in diesem Set ist, als Ergebnis der Dämonisierung, stderr geschlossen und alle Warnungen gehen verloren. Diese Warnung am Ende cmd_gc() ist besonders wichtig, weil es dem Benutzer sagt, wie er vermeiden kann “gc --auto„laufen immer wieder.
Da stderr geschlossen ist, weiß der Benutzer es nicht, natürlich beschweren sie sich über ‘gc --auto‘ CPU-Verschwendung.

Dämonisiert gc spart jetzt stderr zu $GIT_DIR/gc.log.
Folgend gc --auto läuft nicht und gc.log ausgedruckt, bis der Benutzer entfernt gc.log.

Ich verwende git gc, nachdem ich eine große Kasse gemacht habe und viele neue Objekte habe. es kann Platz sparen. Wenn Sie zB ein großes SVN-Projekt mit git-svn auschecken und ein git gc ausführen, sparen Sie normalerweise viel Platz