Holen Sie sich die Git-Zweiggröße

Ich versuche, die Größe eines Projekts zu verfolgen, an dem ich arbeite. Gibt es eine einfache Möglichkeit, die Repository-Größe auf der Festplatte für verschiedene Branches zu ermitteln?

Ich habe es versucht

git count-objects -v

Aber es gibt die gleiche Repository-Größe für jeden Zweig.

Mit Git 2.31 (Q1 2021), “git rev-list“^(Mann) Befehl gelernt --disk-usage Möglichkeit.

Es hat ein viele Beispieleaber in Bezug auf die Zweiggröße lautet der Befehl jetzt:

git rev-list --disk-usage --objects HEAD..<branch_name>

Für alle Filialen:

/* Report the disk size of each branch, not including objects used by the
  current branch. This can find outliers that are contributing to a
  bloated repository size (e.g., because somebody accidentally committed
  large build artifacts).
*/

git for-each-ref --format="%(refname)" |
while read branch
do
    size=$(git rev-list --disk-usage --objects HEAD..$branch)
    echo "$size $branch"
done |
sort -n

Sehen a1db097 übergeben, begehen 669b458 (17. Februar 2021) und 16950f8 übernehmen, Commit 3803a3a (09.02.2021) von Jeff König (peff).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in übertrage 6fe12b525.02.2021)}

rev-list: Option –disk-usage zum Berechnen der Festplattennutzung hinzufügen

^{Unterzeichnet von: Jeff King}

Es kann manchmal nützlich sein, zu sehen, welche Refs zur Gesamtgröße des Repositorys beitragen (z. B. hat ein Zweig eine Reihe von Objekten, die an keiner anderen Stelle im Verlauf gefunden wurden, was darauf hindeutet, dass das Löschen die Größe eines Klons verringern würde).

Sie können das herausfinden, indem Sie eine Liste von Objekten erstellen, ihre Größe aus der Cat-Datei abrufen und sie dann summieren, wie zum Beispiel:

git rev-list --objects --no-object-names main..branch
git cat-file --batch-check='%(objectsize:disk)' |
perl -lne '$total += $_; END { print $total }'

Beachten Sie jedoch, dass hier die Vorbehalte von git-cat-file(1) gelten.
Wir “beschuldigen” Basisobjekte mehr als ihre Deltas, obwohl die Beziehung leicht umgedreht werden könnte.
Dennoch kann es ein nützliches grobes Maß sein.

Aber ein Problem ist, dass es langsam läuft.
Das Anlernen der Drehzahlliste zum Zusammenfassen der Größen kann aus zwei Gründen viel schneller sein:

1. Es überspringt alle Rohrleitungen von Objektnamen und -größen.
2. Wenn Bitmaps verwendet werden, können wir für Objekte, die sich in der Bitmap-Packdatei befinden, die oid_object_info() vollständig nachschlagen und einfach den revindex nach der Größe auf der Festplatte fragen.

Dieser Patch implementiert a --disk-usage Option, die in einem Bruchteil der Zeit dieselbe Antwort liefert.
Hier sind einige Timings mit einem Klon von Torvalds/Linux:

[rev-list piped to cat-file, no bitmaps]
$ time git rev-list --objects --no-object-names --all |
  git cat-file --buffer --batch-check='%(objectsize:disk)' |
  perl -lne '$total += $_; END { print $total }'
1459938510
real  0m29.635s
user  0m38.003s
sys   0m1.093s

[internal, no bitmaps]
$ time git rev-list --disk-usage --objects --all
1459938510
real  0m31.262s
user  0m30.885s
sys   0m0.376s

Auch wenn die Wall-Clock-Zeit aufgrund der Parallelität etwas schlechter ist, beachten Sie die CPU-Einsparungen zwischen den beiden.
Wir haben 21 % der CPU eingespart, indem wir einfach die Pipes vermieden haben.

Aber der wirkliche Gewinn ist mit Bitmaps.
Wenn wir sie ohne die neue Option verwenden:

[rev-list piped to cat-file, bitmaps]
$ time git rev-list --objects --no-object-names --all --use-bitmap-index |
  git cat-file --batch-check='%(objectsize:disk)' |
  perl -lne '$total += $_; END { print $total }'
1459938510
real  0m6.244s
user  0m8.452s
sys   0m0.311s

dann sind wir schneller bei der Generierung der Objektliste, aber wir verbringen immer noch viel Zeit damit, Dinge zu leiten und nachzuschlagen.
Aber wenn wir beides zusammen machen:

[internal, bitmaps]
$ time git rev-list --disk-usage --objects --all --use-bitmap-index
1459938510
real  0m0.219s
user  0m0.169s
sys   0m0.049s

dann erhalten wir die gleiche Antwort viel schneller.

Für “–all” wird diese Antwort natürlich eng mit “du objects/pack” korrespondieren.
Aber wir überprüfen hier eigentlich die Erreichbarkeit, also sind wir immer noch schnell, wenn wir nach interessanteren Dingen fragen:

$ time git rev-list --disk-usage --use-bitmap-index v5.0..v5.10
374798628
real  0m0.429s
user  0m0.356s
sys   0m0.072s

rev-list-options schließt jetzt in seine ein Manpage:

--disk-usage

Normale Ausgabe unterdrücken; Geben Sie stattdessen die Summe der Bytes aus, die von den ausgewählten Commits oder Objekten für die Speicherung auf der Festplatte verwendet werden. Dies entspricht dem Weiterleiten der Ausgabe in git cat-file --batch-check='%(objectsize:disk)'außer dass es viel schneller läuft (besonders mit --use-bitmap-index). Siehe die CAVEATS
Abschnitt ein git cat-file für die Einschränkungen dessen, was “On-Disk-Storage” bedeutet.

Mit Git 2.38 (Q3 2022), “git rev-list --disk-usage“^(Mann) gelernt, einen optionalen Wert anzunehmen human um den gemeldeten Wert in einem für Menschen lesbaren Format anzuzeigen, wie “3.40MiB“.

Sehen Commit 9096451 (11. August 2022) von Li Linchao (Cactusinhand).
^{(Zusammengeführt von Junio ​​C. Hamano — gitster — in fddd8b4 übergeben18.08.2022)}

rev-list: unterstützt menschenlesbare Ausgabe für --disk-usage

^{Unterzeichnet von: Li Linchao}

Die ‘--disk-usage‘Option für git-rev-list^(Mann) eingeführt wurde 16950f8 (“rev-list: add^(Mann) --disk-usage Option zur Berechnung der Festplattennutzung”, 09.02.2021, Git v2.31.0-rc0 — verschmelzen).

Dies ist sehr nützlich für Leute, die die Nutzungsinformationen ihrer Git-Repository-Objekte überprüfen, aber die resultierende Zahl ist für einen Menschen ziemlich schwer zu lesen.

Unterrichten git rev-list um ein für Menschen lesbares Ergebnis auszugeben, wenn ‘–disk-usage=human’ verwendet wird.

rev-list-options schließt jetzt in seine ein Manpage:

Mit dem optionalen Wert humanwird die Speichergröße auf der Festplatte in einer für Menschen lesbaren Zeichenfolge angezeigt (z 12.24 Kib, 3.50 Mib).

Hier ist etwas wirklich hässliches:

$ git rev-list HEAD |                     # list commits
  xargs -n1 git ls-tree -rl |             # expand their trees
  sed -e 's/[^ ]* [^ ]* \(.*\)\t.*/\1/' | # keep only sha-1 and size
  sort -u |                               # eliminate duplicates
  awk '{ sum += $2 } END { print sum }'   # add up the sizes in bytes

Dies zählt nur die Blobs (keine Commits, Bäume usw.) und berücksichtigt weder das Packen noch die branchenübergreifende gemeinsame Nutzung von Objekten. Aber es könnte als Grundlage für etwas Nützliches dienen.

Einfügbare Version:

git rev-list HEAD | xargs -n1 git ls-tree -rl | sed -e 's/[^ ]* [^ ]* \(.*\)\t.*/\1/' | sort -u | awk '{ sum += $2 } END { print sum }'

Diese Frage ist nicht wirklich sinnvoll – in Git werden Branches nicht separat gespeichert. Stattdessen gibt es ein Netz von Commits, und im Grunde werden nur die Diffs gespeichert. Die Verzweigungen sind nur Zeiger auf bestimmte Commits in diesem Web von Commits. Im Allgemeinen teilen Zweige also viele der gleichen Informationen.

Wenn Sie die Größe des Speicherplatzes eines einzelnen Zweigs wissen möchten, d. h. die minimale Menge an Speicherplatz, die jemand benötigt, wenn er das Repo klont und nur diesen Zweig verwendet, ist es wahrscheinlich am einfachsten, einfach so ein Repo zu erstellen. und fragen Sie dann nach der Größe dieses Repos.

1. Klonen Sie Ihr Repository.
2. schauen Sie in Ihrer Fachbranche nach.
3. Größe des Projektverzeichnisses – Größe der .git-Datei des Repos = Größe des Zweigs. Hinweis: .git beinhaltet index\ref\tags\objects des Repos.