Git peu profonde submodules

Question

Est-il possible d'avoir peu profonde submodules? J'ai un superproject avec plusieurs submodules, chacun avec une histoire longue, de sorte qu'il devient inutilement gros glisser tout ce que l'histoire.

Tout ce que j'ai trouvé est ce fil sans réponse.

Devrais-je hack git-sous-module pour mettre en œuvre cette?

Answer 1

Nouveau dans la prochaine git1.8.4 (juillet 2013):

"git submodule update" peut éventuellement clone le sous-module dépôts faiblement.

Voir commettre 275cd184d52b5b81cb89e4ec33e540fb2ae61c1f:

Ajouter l' --depth option pour ajouter et mettre à jour les commandes de "git sous-module", qui est ensuite transmis à la commande clone. Cela est utile lorsque le sous-module(s) sont énormes et vous n'êtes pas vraiment intéressé par quelque chose, mais le dernier commit.

Les Tests sont ajoutés et le retrait de certains ajustements ont été faits pour s'aligner sur le reste de la testfile sur "sous-module de mise à jour peut gérer les liens symboliques dans pwd".

Signed-off-by: Fredrik Gustafsson <iveqy@iveqy.com>
Roupe animé par: Jens Lehmann <Jens.Lehmann@web.de>

Cela signifie que cela fonctionne:

git submodule add --depth 1 -- repository path
git submodule update --depth -- [<path>...]

Avec:

--depth::

Cette option est valable pour l' add et update des commandes.
Créer un "shallow" clone avec une histoire tronquée pour le nombre spécifié de révisions.

Answer 2

Suite à la réponse de Ryan , j'ai été en mesure de venir avec cette simple script qui parcourt toutes les submodules et peu profondes des clones:

#!/bin/bash
git submodule init
for i in $(git submodule | sed -e 's/.* //'); do
    spath=$(git config -f .gitmodules --get submodule.$i.path)
    surl=$(git config -f .gitmodules --get submodule.$i.url)
    git clone --depth 1 $surl $spath
done
git submodule update

Answer 3

De la lecture à travers le git-sous-module "source", il ressemble git submodule add peut gérer submodules qui ont déjà leurs dépôts présents. Dans ce cas...

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
$ git submodule add $remotesub1 $sub1
#repeat as necessary...

Vous voudrez vous assurer que le nécessaire commettre est dans le sous-module repo, alors assurez-vous de définir un --profondeur.

Edit: Vous pouvez être en mesure de s'en tirer avec de multiples manuel sous-module clones suivie par une mise à jour unique:

$ git clone $remote1 $repo
$ cd $repo
$ git clone --depth 5 $remotesub1 $sub1
#repeat as necessary...
$ git submodule update

Answer 4

Sont canoniques de l'emplacement des submodules à distance? Si oui, êtes-vous OK avec le clonage d'une fois? En d'autres termes, voulez-vous le peu de clones juste parce que vous souffrez de la perte de la bande passante de fréquentes sous-module (re)clones?

Si vous voulez peu profonde clones pour enregistrer les locaux de l'espace disque, puis Ryan Graham réponse semble être une bonne façon d'aller. Manuellement clone les dépôts, de sorte qu'ils sont peu profonds. Si vous pensez qu'il serait utile, d'adapter git submodule à la soutenir. Envoyer un email à la liste de demander à ce sujet (des conseils pour sa mise en œuvre, des suggestions sur l'interface, etc.). À mon avis, les gens y sont très favorables à des contributeurs potentiels que voulez véritablement à améliorer Git de manière constructive.

Si vous êtes OK avec le fait de plein de clone de chaque sous-module (plus tard, extrait de les conserver jusqu'à la date), vous pouvez essayer en utilisant l' --reference option de git submodule update (c'est dans Git 1.6.4 et plus tard) pour faire référence à l'objet local magasins (ex. --mirror des clones de la structure canonique sous-module dépôts, puis utilisez --reference dans votre submodules à point à ces clones locaux). Juste être sûr de lire à propos de git clone --reference/git clone --shared avant d'utiliser --reference. Le seul problème probable avec le référencement miroirs serait si jamais ils finissent par aller chercher de non-avance rapide des mises à jour (bien que vous pouvez activer reflogs et d'élargir leur expiration de windows pour aider à conserver abandonnés s'engage à ce que pourrait poser un problème). Vous ne devriez pas avoir de problèmes tant que

• vous ne faites pas de local sous-module s'engage, ou
• toutes les commits qui sont laissés ballants par des non-avancer rapidement que les canonique dépôts pourrait publier ne sont pas les ancêtres de votre local sous-module s'engage, ou
• vous êtes diligent au sujet de garder votre local sous-module s'engage relocalisée sur le dessus de ce que les non-avance peut-être publiés dans la structure canonique sous-module de référentiels.

Si vous allez avec quelque chose comme cela et il y a toute chance que vous pourriez réaliser local sous-module s'engage dans votre travail d'arbres, il serait probablement une bonne idée de créer un système automatisé qui permet de s'assurer critique les objets référencés par l'extrait submodules ne sont pas les laisser pendre dans le miroir des référentiels (et si il y en a, des copies pour les dépôts qui en ont besoin).

Et, comme l' git clone man dit, ne pas utiliser --reference si vous ne comprenez pas ces conséquences.

# Full clone (mirror), done once.
git clone --mirror $sub1_url $path_to_mirrors/$sub1_name.git
git clone --mirror $sub2_url $path_to_mirrors/$sub2_name.git

# Reference the full clones any time you initialize a submodule
git clone $super_url super
cd super
git submodule update --init --reference $path_to_mirrors/$sub1_name.git $sub1_path_in_super
git submodule update --init --reference $path_to_mirrors/$sub2_name.git $sub2_path_in_super

# To avoid extra packs in each of the superprojects' submodules,
#   update the mirror clones before any pull/merge in super-projects.
for p in $path_to_mirrors/*.git; do GIT_DIR="$p" git fetch; done

cd super
git pull             # merges in new versions of submodules
git submodule update # update sub refs, checkout new versions,
                     #   but no download since they reference the updated mirrors

---

Alternativement, au lieu de --reference, vous pouvez utiliser le miroir des clones en combinaison avec la valeur par défaut hardlinking fonctionnalité de git clone à l'aide des miroirs, comme la source de votre submodules. Dans les nouveaux super-projet de clones, n' git submodule init, de modifier le sous-module d'Url en .git/config pour pointer vers le local des miroirs, puis procédez de l' git submodule update. Vous devez reclone existants extrait submodules pour obtenir les liens physiques. Vous économisez de la bande passante en téléchargement uniquement une fois dans les rétroviseurs, puis aller chercher localement à partir de celles de votre check-out, submodules. La difficile liaison permettrait d'économiser de l'espace disque (bien que l'extrait aurait tendance à s'accumuler et être dupliquée dans plusieurs instances de l'extrait submodules' objet de magasins; vous pourriez périodiquement reclone l'extrait submodules à partir des miroirs pour retrouver le disque d'économiser de l'espace fourni par hardlinking).