Was bedeutet Tiefe für Git-Klon?

Lesezeit: 6 Minuten

Benutzer-Avatar
Machta

Wir haben versucht, den CI-Build eines unserer Softwareprojekte bei der Arbeit zu beschleunigen. Jemand hat früh im Leben des Projekts einige riesige (nach Git-Standards) Binärdateien übergeben. Das Umschreiben des Verlaufs von git, nur um sie loszuwerden, scheint zu viel Mühe zu sein, also dachten wir, dass es gut genug wäre, einen flachen Klon zu erstellen, der diese großen frühen Commits vermeidet.

Ich habe einige Experimente mit gemacht --depth Parameter für Klonen und stieß auf ein seltsames Verhalten. Das sagt help for git clone dazu:

--depth <depth>
           Create a shallow clone with a history truncated to the specified number of commits. Implies
           --single-branch unless --no-single-branch is given to fetch the histories near the tips of all
           branches. If you want to clone submodules shallowly, also pass --shallow-submodules.

Dies würde darauf hindeuten <depth> entspricht der Anzahl der Commits, die während des Klonens abgerufen werden, aber das ist nicht der Fall. Dies ist, was ich bekam, als ich verschiedene Werte für die Tiefe ausprobierte:

| depth   | commit count linux repo | commit count git repo |
|---------|-------------------------|-----------------------|
| 1       | 1                       | 1                     |
| 5       | 15                      | 13                    |
| 10      | 80                      | 46                    |
| 100     | 93133                   | 39552                 |
| 1000    | 788718                  | 53880                 |

Zum Klonen habe ich diesen Befehl verwendet git clone --depth 10 https://github.com/torvalds/linux.git, git clone --depth 100 https://github.com/git/git.gitund zum Zählen der Commits habe ich dies verwendet git log --oneline | wc -l. (Bei der Arbeit habe ich dasselbe mit einem GitLab-Server beobachtet, daher kann es kein Artefakt der Funktionsweise von GitHub sein.)

Weiß jemand was los ist? Wie entspricht der Wert für die Tiefe der tatsächlich heruntergeladenen Datenmenge? Verstehe ich die Dokumentation falsch, oder ist da ein Bug?

BEARBEITEN: Ich habe Ergebnisse für ein zweites Repo hinzugefügt

  • Ich kann mir vorstellen, dass Merge-Commits beeinflussen könnten, was Sie sehen.

    – Jonathon Reinhart

    8. Dezember 2018 um 15:21 Uhr

Wie Jonathon Reinhart kommentierte, sehen Sie die Wirkung von Zusammenführungen.

Das --depth Der Parameter bezieht sich darauf, wie tief Git von jedem Startpunkt aus „spazieren“ geht. Wie die von Ihnen zitierte Dokumentation erwähnt, impliziert dies auch --single-branch, was das Sprechen vereinfacht. Der wichtige Punkt hier ist, dass der Spaziergang besucht alle Eltern jedes Commit, was – für jede Tiefenstufe – mehr als ein Commit ist, wenn das Commit selbst eine Zusammenführung ist.

Angenommen, wir haben ein Commit-Diagramm, das so aussieht:

$ git log --graph --oneline master
* cf68824 profile: fix PATH with GOPATH
* 7c2376b profile: add Ruby gem support
* 95c8270 profile: set GOPATH
* 26a9cc3 vimrc: fiddle with netrw directory display
* 80b88a5 add ruby gems directory to path
[snip]

Hier hat jeder Commit nur einen Elternteil. Wenn wir verwenden --depth 3 Wir holen das Trinkgeld ab cf68824sein Elternteil 7c2376b in Tiefe 2 und schließlich 95c8270 bei Tiefe 3 – und dann hören wir mit drei Commits auf.

Mit dem Git-Repository für Git jedoch:

$ git log --graph --oneline master
*   965798d1f2 Merge branch 'es/format-patch-range-diff-fix-fix'
|\  
| * ac0edf1f46 range-diff: always pass at least minimal diff options
* |   5335669531 Merge branch 'en/rebase-consistency'
|\ \  
| * | 6fcbad87d4 rebase docs: fix incorrect format of the section Behavioral Differences
* | | 7e75a63d74 RelNotes 2.20: drop spurious double quote
* | | 7a49e44465 RelNotes 2.20: clarify sentence
[snip]

Mit --depth 3beginnen wir mit 965798d1f2dann – für Tiefe 2 – abheben beide Eltern, ac0edf1f46 und 5335669531. Um die Tiefe-3-Commits hinzuzufügen, nehmen wir alle Eltern dieser beiden Commits auf. Der (einsame) Elternteil von ac0edf1f46 ist hier nicht sichtbar, während die beiden Eltern von 5335669531 sind (nämlich 6fcbad87d4 und 7e75a63d74). Um die Hash-IDs der Eltern von zu erhalten ac0edf1f46 wir können benutzen:

$ git rev-parse ac0edf1f46^@
d8981c3f885ceaddfec0e545b0f995b96e5ec58f

Das gibt uns also unsere sechs Commits: die Spitze von master (der derzeit ein Merge-Commit ist), zwei Eltern dieses Commits, ein Elternteil von einem dieser Eltern und zwei Eltern des anderen von diesem Elternteil.

Je nachdem, wann Sie den Klon von Git ausgeführt haben, ist die Spitze am höchsten master ist oft kein Merge, hat aber oft einen Merge als unmittelbares Elternteil, so dass --depth 2 erhalten Sie oft 3 Commits, und --depth 3 wird daher bekommen wenigstens 5, je nachdem, ob die beiden Elternteile der Spitze master sind selbst Fusionen.

(Vergleiche oben git rev-parse Ausgabe mit:

$ git rev-parse 965798d1f2^@
5335669531d83d7d6c905bcfca9b5f8e182dc4d4
ac0edf1f46fcf9b9f6f1156e555bdf740cd56c5f

zum Beispiel. Das ^@ Suffix bedeutet alle Eltern des Commit, aber nicht das Commit selbst.)

Benutzer-Avatar
CodeWizard

--depth bedeutet die Anzahl der Commits, die beim Klonen abgerufen werden müssen.

Standardmäßig git-Download Ihre ganze Geschichte aller Filialen. Das bedeutet, dass Ihre Kopie den gesamten Verlauf haben muss, sodass Sie in der Lage sein werden, zu jedem gewünschten Commit zu wechseln (zu checken).

Hinzufügen der --depth begrenzen Sie die Größe Ihres Klons und checken Sie nur die X letzten Commits aus

# Cloning a  single branch with the following:
# clone specific branch and limit the history to last X commits
git clone --branch<...> --depth=<X>

Wie entspricht der Wert für die Tiefe der tatsächlich heruntergeladenen Datenmenge? mit dem --depth git wird nur Laden Sie den Inhalt herunter, der den Commits im angegebenen Bereich entspricht, sodass die Größe des Repos ansteigt, wenn der Wert größer ist


Dies würde darauf hinweisen, dass dies der Anzahl der Commits entspricht, die während der abgerufen werden

Wenn einer dieser Commits eine Zusammenführung ist (z. B. kein schneller Vorlauf), erhalten Sie nicht immer mehr als X Commits.


So bereinigen Sie Ihre Binärdatei:

Den Verlauf von git umzuschreiben, nur um sie loszuwerden, scheint zu viel Mühe zu sein

Dieses Tool kann es für Sie tun:

https://rtyley.github.io/bfg-repo-cleaner

###BFG Repo-Cleaner

eine Alternative zu git-filter-branch.

Das BFG ist eine einfachere, schnellere Alternative zu git-filter-branch für die Bereinigung schlechte Daten aus Ihrem Git-Repository-Verlauf:

*** Verrückte große Dateien entfernen ***

  • Entfernen von Passwörtern, Anmeldeinformationen und anderen privaten Daten

Beispiele (von der offiziellen Seite) In all diesen Beispielen ist bfg ein Alias ​​für java -jar bfg.jar.

# Delete all files named 'id_rsa' or 'id_dsa' :
bfg --delete-files id_{dsa,rsa}  my-repo.git

  • Ich bin mir nicht sicher, ob dies die Frage des OP wirklich beantwortet. Das OP gab Beispiele dafür, dass die Tiefe nicht so ist, wie sie erwartet wurde. Die Beispiele, die das OP gegeben hat, stimmen nicht mit dem überein, was Sie über den Tiefenbefehl gesagt haben.

    – Charlie Fisch

    8. Dezember 2018 um 15:31 Uhr

  • Das ist nett, aber es beantwortet die Frage nicht. Ich weiß, dass es dafür Tools gibt (ich habe dieses Tool sogar schon einmal verwendet). Aber es sei denn, es gibt eine Möglichkeit, dies zu tun, ohne die Geschichte neu zu schreiben, es ist ein No-Go für mich.

    – Machta

    8. Dezember 2018 um 15:31 Uhr


  • Übrigens könnte dies das Schlimmste an Git sein. Einmal gedrückt, ist es für immer da. Es sei denn, Sie möchten nicht, dass die Leute Sie anschreien, das heißt … (Ja, das ist schon einmal passiert. OK, es war ein bisschen weniger dramatisch 🙂 Das ist ein riesiger Fallstrick für Gitarristen. Ich möchte eine Warnung, wenn Sie mit git -A eine Binärdatei hinzufügen, die größer als beispielsweise 100 KB ist.

    – Machta

    8. Dezember 2018 um 15:48 Uhr

  • Sie können dazu Git-Hooks verwenden. GITHUB hat Sie in den letzten Jahren davor gewarnt

    – CodeWizard

    8. Dezember 2018 um 15:52 Uhr

1205740cookie-checkWas bedeutet Tiefe für Git-Klon?

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

Privacy policy