Git flache Submodule

Neu in der kommenden git1.8.4 (Juli 2013) :

  

" git submodule update " kann optional die Submodul-Repositories flach klonen.

(Und git 2.10 Q3 2016 erlaubt das mit git config -f .gitmodules submodule.<name>.shallow true aufzuzeichnen.
Siehe das Ende dieser Antwort)

Siehe commit 275cd184d52b5b81cb89e4ec33e540fb2ae61c1f :

  

Fügen Sie den Befehlen add und update von "git submodule" die Option --depth hinzu, die dann an den Befehl clone übergeben wird. Dies ist nützlich, wenn das (die) Submodul (en) riesig sind und Sie an nichts wirklich interessiert sind außer an dem letzten Commit.

     

Tests wurden hinzugefügt, und einige Einrückungen wurden vorgenommen, um dem Rest der Testdatei zu entsprechen. "Das Submodul-Update kann mit symbolischen Links in pwd umgehen".

     

Abgesandt von: Fredrik Gustafsson <[email protected]>
  Gezogen von: Jens Lehmann <[email protected]>

Das heißt, das funktioniert:

Mit:

  

Diese Option ist für die Befehle add und update gültig.
  Erstellen Sie einen 'seichten' Klon mit einem auf die angegebene Anzahl von Revisionen gekürzten Verlauf.

atwyman fügt in den Kommentaren :

  

Soweit ich das beurteilen kann, ist diese Option nicht für Submodule verwendbar, die master nicht sehr genau verfolgen. Wenn Sie die Tiefe 1 festlegen, kann submodule update nur dann erfolgreich sein, wenn das gewünschte Submodul-Commit der letzte Master ist. Andernfalls erhalten Sie " fatal: reference is not a tree " .

Das ist wahr.
Das heißt, bis Git 2.8 (März 2016). Mit 2.8 hat der submodule update --depth eine Chance mehr, erfolgreich zu sein, auch wenn der SHA1 direkt von einem der Remote-Repo-HEADs erreichbar ist.

Siehe commit fb43e31 (24. Februar 2016) von Stefan Beller ( stefanbeller ) .
Unterstützt von: Junio ​​C Hamano ( gitster ) .
^{(Zusammengeführt von Junio ​​C Hamano - gitster - in commit 9671a76 , 26. Feb. 2016)}

  

Submodul: Versuchen Sie, die benötigte sha1 durch direktes Holen von sha1

zu holen      

Wenn Sie eine Änderung prüfen, die auch ein Submodul in Gerrit aktualisiert, besteht eine gängige Praxis darin, den Patch lokal herunterzuladen und auszuwählen, um ihn zu testen.
  Bei einem lokalen Test kann ' git submodule update ' jedoch nicht das korrekte Submodul sha1 abrufen, da das entsprechende Commit im Submodul noch nicht Teil des Projektverlaufs ist, sondern nur eine vorgeschlagene Änderung.

     

Wenn $sha1 nicht zum Standard-Fetch gehört, versuchen wir, $sha1 direkt zu holen. Einige Server unterstützen jedoch nicht den direkten Abruf von sha1, was dazu führt, dass git-fetch schnell fehlschlägt.
  Wir können hier selbst versagen, da der noch fehlende Sha1 sowieso später in der Checkout-Phase zu einem Fehler führen würde, also ist das Scheitern hier so gut, wie wir bekommen können.

MVG weist darauf hin in den Kommentaren zu commit fb43e31 (git 2.9, Feb 2016) )

  

Es scheint mir, dass commit fb43e31 das fehlende Commit der SHA1-ID anfordert, also das uploadpack.allowReachableSHA1InWant und uploadpack.allowTipSHA1InWant Einstellungen auf dem Server werden wahrscheinlich beeinflussen, ob dies funktioniert.
  Ich schrieb heute einen Beitrag auf die Git-Liste und wies auf die Verwendung von flachen Submodulen hin könnte für einige Szenarien besser funktionieren, wenn das Commit auch ein Tag ist.
  Warten wir ab und sehen.

     

Ich nehme an, das ist ein Grund, warum fb43e31 das Fetch für einen bestimmten SHA1 nach dem Fetch für den Standard-Branch zu einem Fallback gemacht hat.
  Im Fall von "--depth 1" wäre es jedoch sinnvoll, früh abzubrechen: Wenn keine der aufgelisteten Referenzen mit der angeforderten übereinstimmt, und die Abfrage von SHA1 vom Server nicht unterstützt wird, dann hat das keinen Sinn etwas holen, da wir die Submodul-Anforderung in keiner Weise erfüllen können.

Update August 2016 (3 Jahre später)

Mit Git 2.10 (Q3 2016) können Sie

Siehe " Git Submodul ohne zusätzliches Gewicht " für mehr.

Git 2.13 (Q2 2017) hinzufügen commit 8d3047c (19 Apr 2017) von Sebastian Schuberth ( sschuberth ) .
^{(Zusammengefasst von Sebastian Schuberth - sschuberth - in commit 8d3047c , 20 Apr 2017)}

  

Ein Klon dieses Submoduls wird als flacher Klon (mit einer History-Tiefe von 1)

ausgeführt

Ciro Santilli fügt jedoch in den Kommentaren (und Details in seiner Antwort )

  

shallow = true on .gitmodules wirkt sich nur auf die Referenz aus, die vom HEAD der Gegenstelle verfolgt wird, wenn --recurse-submodules verwendet wird, auch wenn auf die Zielfestschreibung durch eine Verzweigung verwiesen wird, und selbst wenn Sie branch = mybranch auf% setzen auch co_de%.

Nach Ryans Antwort konnte ich mir dieses einfache Skript vorstellen, das durch alle geht Submodule und flache Klone sie:

Git 2.9.0 unterstützt Submodule flach Klon direkt Jetzt kannst du einfach anrufen:

Beim Lesen des git-Submoduls "source" sieht es so aus, als ob git submodule add mit Submodulen umgehen kann, die bereits ihre Repositories haben. In diesem Fall ...

Sie sollten sicherstellen, dass die erforderliche Festschreibung im Repo des Submoduls ist. Stellen Sie daher sicher, dass Sie eine entsprechende - Tiefe angeben.

Bearbeiten: Sie können möglicherweise mit mehreren manuellen Submodul Klonen gefolgt von einem einzigen Update kommen:

Sind die kanonischen Standorte für Ihre Submodule entfernt? Wenn ja, ist es in Ordnung, sie einmal zu klonen? Mit anderen Worten, wollen Sie die flachen Klone, nur weil Sie die verschwendete Bandbreite von häufigen Submodul (Re) Klonen leiden?

Wenn Sie möchten, dass flache Klone lokalen Speicherplatz sparen, dann scheint Ryan Grahams Antwort ein guter Weg zu sein. Klonen Sie die Repositorys manuell so, dass sie flach sind. Wenn Sie denken, dass es nützlich wäre, passen Sie git submodule an, um es zu unterstützen. Senden Sie eine E-Mail an die Liste und fragen Sie danach (Ratschlag zur Implementierung, Vorschläge zur Benutzeroberfläche usw.) ). Meiner Meinung nach unterstützen die Leute dort potentielle Mitwirkende, die Git konstruktiv verbessern wollen.

Wenn Sie mit einem vollständigen Klon jedes Submoduls fertig sind (plus spätere Abrufe, um sie aktuell zu halten), könnten Sie versuchen, die Option --reference von git submodule update zu verwenden (sie ist in Git 1.6.4 und höher) ) um auf lokale Objektspeicher zu verweisen (zB make --mirror Klone der kanonischen Submodul-Repositorys, dann --reference in Ihren Submodulen verwenden, um auf diese lokalen Klone zu zeigen). Stellen Sie sicher, dass Sie über git clone --reference / git clone --shared lesen, bevor Sie --reference verwenden. Das einzige wahrscheinliche Problem bei der Referenzierung von Spiegeln wäre, wenn sie jemals Nicht-Fast-Forward-Updates abrufen würden (obwohl Sie Reflogs aktivieren und ihre Verfallsfenster erweitern könnten, um eventuell zurückgelassene Commits beizubehalten, die ein Problem verursachen könnten). Solange

• Sie machen keine lokalen Untermodule oder
• Alle Commits, die von Nicht-Fast-Forwards hängen gelassen werden, die von den kanonischen Repositorys veröffentlicht werden, sind keine Vorfahren für die Commits Ihres lokalen Submoduls oder
• Sie sind fleißig dabei, Ihre lokalen Submodul-Commits auf allen Nicht-Fast-Forwards zu rebasieren, die in den kanonischen Submodul-Repositories veröffentlicht werden.

Wenn Sie mit so etwas gehen und die Möglichkeit besteht, dass Sie lokale Submodul-Commits in Ihren Arbeitsbäumen ausführen, ist es wahrscheinlich eine gute Idee, ein automatisiertes System zu erstellen, das kritische Objekte sicherstellt, auf die das ausgecheckte Objekt verweist Submodule bleiben nicht in den Spiegel-Repositories hängen (und wenn sie gefunden werden, werden sie in die Repositories kopiert, die sie benötigen).

Und, wie die git clone Manpage sagt, verwenden Sie --reference nicht, wenn Sie diese Implikationen nicht verstehen.

Alternativ können Sie anstelle von --reference die Mirror Clones in Kombination mit der standardmäßigen Hardlinking-Funktion git clone verwenden, indem Sie lokale Spiegel als Quelle für Ihre Submodule verwenden. In neuen Super-Projekt-Klonen tun Sie git submodule init , bearbeiten Sie die Submodul-URLs in .git/config , um auf die lokalen Spiegel zu verweisen, und führen Sie dann git submodule update aus. Sie müssen alle vorhandenen ausgecheckten Submodule neu klonen, um die Hardlinks zu erhalten. Sie würden Bandbreite sparen, indem Sie nur einmal in die Spiegel herunterladen und dann lokal von diesen in Ihre ausgecheckten Submodule holen. Die feste Verknüpfung würde Speicherplatz sparen (obwohl Abrufvorgänge dazu neigen würden, sich über mehrere Instanzen der Objektspeicher der ausgecheckten Submodule hinweg zu akkumulieren und zu duplizieren; Sie könnten periodisch die ausgecheckten Submodule von den Spiegelungen neu einclonen, um die Speicherplatzersparnis von Hardlinking).

Ich habe eine etwas andere Version erstellt, wenn sie nicht auf dem neuesten Stand ist, was nicht alle Projekte tun. Die Erweiterungen des Standard-Submoduls funktionierten nicht und auch nicht das obige Skript. Also habe ich einen Hash-Lookup für das Tag Ref hinzugefügt, und wenn es keinen hat, fällt es auf den vollständigen Klon zurück.

Verweis auf Klonen des Git-Repositorys mit spezifischer Revision / Changeset?

Ich habe ein einfaches Skript geschrieben, das kein Problem hat, wenn Ihre Submodul-Referenz vom Master entfernt ist

Diese Anweisung ruft die referenzierte Version des Submoduls ab.

Es ist schnell, aber Sie können Ihre Bearbeitung für das Submodul nicht bestätigen (Sie müssen es unsachlich abholen, bevor Ссылка )

vollständig:

Zusammenfassung des Buggy / unerwarteten / nervigen Verhaltens ab Git 2.14.1

1. shallow = true in .gitmodules wirkt sich nur auf git clone --recurse-submodules aus, wenn die HEAD des Remote-Submoduls auf die erforderliche Festschreibung verweist, auch wenn auf die Zielfestschreibung durch eine Verzweigung verwiesen wird, und selbst wenn Sie branch = mybranch setzen auch auf dem .gitmodules .

   Lokales Testskript . Gleiches Verhalten auf GitHub 2017-11, wobei HEAD von der Standardeinstellung für Zweig-Repos gesteuert wird:

   %Vor%

2. git clone --recurse-submodules --shallow-submodules schlägt fehl, wenn auf die Festschreibung weder von einer Verzweigung noch von einem Tag mit einer Nachricht verwiesen wird: error: Server does not allow request for unadvertised object .

   lokales Testskript . Gleiches Verhalten auf GitHub:

   %Vor%

   Ich fragte auch auf der Mailingliste: Ссылка und die Antwort war:

     

   Theoretisch sollte das einfach sein. :)

        

   In der Praxis leider nicht so viel. Dies liegt daran, dass das Klonen nur erhalten wird   der neueste Tipp einer Branche (meist Master). Es gibt keinen Mechanismus im Klon   um das genaue sha1 anzugeben, das gewünscht wird.

        

   Das Wire-Protokoll unterstützt das Abfragen von genauen Sha1s, so dass dies abgedeckt werden sollte.   (Vorbehalt: Es funktioniert nur, wenn der Server-Operator aktiviert   uploadpack.allowReachableSHA1InWant welche github hat nicht AFAICT)

        

   git-fetch ermöglicht das beliebige sha1 zu holen, so dass Sie einen Fetch ausführen können   nach dem rekursiven Klon mit "git submodule update", wie es verwendet wird   Ruft nach dem ersten Klon ab.