À partir de la version 2.5+ de Git (T2 2015), il est possible de récupérer un seul commit (sans cloner le repository complet).

Voir commit 68ee628 par Fredrik Medley ( moroten ) , 21 mai 2015.
^{(Fusionné par Junio ​​C Hamano – gitster – dans commit a9d3493 , 01 juin 2015)}

Vous avez maintenant une nouvelle configuration (côté serveur)

 uploadpack.allowReachableSHA1InWant 

Permettre à upload-pack d’accepter une requête d’extraction qui demande un object accessible depuis n’importe quel conseil de référence. Cependant, notez que le calcul de l’accessibilité des objects est coûteux en calcul.
La valeur par défaut est false .

Si vous combinez cette configuration côté serveur avec un clone superficiel ( git fetch --depth=1 ), vous pouvez demander un seul commit (voir t/t5516-fetch-push.sh :

 git fetch --depth=1 ../testrepo/.git $SHA1 

Vous pouvez utiliser la commande git cat-file pour voir que la validation a été récupérée:

 git cat-file commit $SHA1 

” git upload-pack ” qui sert ” git fetch ” peut être dit pour servir les commits qui ne sont pas à la pointe de n’importe quelle référence, tant qu’ils sont accessibles depuis une référence, avec la variable de configuration uploadpack.allowReachableSHA1InWant .

La documentation complète est:

upload-pack : éventuellement autoriser la récupération de sha1 accessible

Avec l’option de configuration uploadpack.allowReachableSHA1InWant définie du côté serveur, ” git fetch ” peut effectuer une requête avec une ligne “want” qui nomme un object qui n’a pas été publié (susceptible d’avoir été obtenu hors bande ou à partir d’un pointeur de sous-module) .
Seuls les objects accessibles à partir des conseils de twig, c’est-à-dire l’union des twigs et des twigs annoncées masquées par transfer.hideRefs , seront traités.
Notez qu’il y a un coût associé à devoir remonter l’historique pour vérifier l’accessibilité.

Cette fonctionnalité peut être utilisée lors de l’obtention du contenu d’un certain commit, pour lequel le sha1 est connu, sans qu’il soit nécessaire de cloner l’intégralité du référentiel, surtout si un extraction superficielle est utilisée .

Les cas utiles sont par exemple

• les repositorys contenant des fichiers volumineux dans l’historique,
• récupérer uniquement les données nécessaires à une vérification de sous-module,
• lorsque vous partagez un sha1 sans indiquer la twig exacte à laquelle il appartient et dans Gerrit, si vous pensez en termes de commits au lieu de numéros de modification.
  (Le cas Gerrit a déjà été résolu grâce à allowTipSHA1InWant car chaque changement Gerrit a une réf.)

Git 2.6 (T3 2015) améliorera ce modèle.
Voir commettre 2bc31d1 , commettre cc118a6 (28 juillet 2015) par Jeff King ( peff ) .
^{(Fusionné par Junio ​​C Hamano – gitster – dans commit 824a0be , 19 août 2015)}

refs : support négatif transfer.hideRefs

Si vous masquez une hiérarchie de références à l’aide de la configuration transfer.hideRefs , il n’y a aucun moyen de remplacer ultérieurement cette configuration pour la “révéler”.
Ce patch implémente un masque “négatif” qui fait que les matchs sont immédiatement marqués comme non masqués, même si un autre match le cacherait.
Nous prenons soin d’appliquer les correspondances en ordre inverse de la façon dont elles nous ont été .git/config par la machine de configuration, car cela nous permet de travailler avec la priorité “dernière victoire” (et les entrées dans .git/config , par exemple, remplaceront /etc/gitconfig ).

Donc, vous pouvez maintenant faire:

 git config --system transfer.hideRefs refs/secret git config transfer.hideRefs '!refs/secret/not-so-secret' 

masquer refs/secret dans tous les repos, sauf pour un bit public dans un repo spécifique.

Git 2.7 (Nov / Dec 2015) va encore s’améliorer:

Voir commit 948bfa2 , commit 00b293e (05 nov 2015), commit 78a766a , commit 92cab49 , commit 92cab49 , commit 92cab49 (03 nov. 2015), valide 00b293e , valide 00b293e (05 nov 2015) et valide 92cab49 , commit 92cab49 , commit 92cab49 , commit 92cab49 (03 nov. 2015) de Lukas Fleischer ( lfos ) .
Aidé par: Eric Sunshine ( sunshineco ) .
^{(Fusion par Jeff King – peff – dans commit dbba85e , 20 nov. 2015)}

config.txt : documente la sémantique de hideRefs avec les espaces de noms

À l’heure actuelle, il n’y a pas de définition claire de la façon dont transfer.hideRefs devrait se comporter lorsqu’un espace de noms est défini.
Expliquez que les préfixes hideRefs correspondent aux noms dépouillés dans ce cas. Voici comment les patterns hideRefs sont actuellement gérés dans le paquet de réception.

hideRefs: ajout du support pour les références complètes

En plus de faire correspondre les hideRefs dénudées, il est désormais possible d’append les patterns hideRefs auxquels la référence complète (non dépouillée) est comparée.
Pour faire la distinction entre les matches dénudés et complets, ces nouveaux motifs doivent être préfixés par un circonflexe ( ^ ).

D’où la nouvelle documentation :

 transfer.hideRefs: 

Si un espace de noms est utilisé, le préfixe d’espace de noms est supprimé de chaque référence avant d’être comparé aux motifs transfer.hiderefs .
Par exemple, si refs/heads/master est spécifié dans transfer.hideRefs et que l’espace de noms actuel est foo , alors les refs/namespaces/foo/refs/heads/master sont omises dans les publicités, sauf refs/heads/master et refs/namespaces/bar/refs/heads/master sont toujours annoncés comme des lignes dites “avoir”.
Pour faire correspondre les refs avant le dépouillement, ajoutez un ^ devant le nom de la référence. Si vous combinez ! et ^ ! doit être spécifié en premier.

R .. mentionne dans les commentaires le uploadpack.allowAnySHA1InWant config uploadpack.allowAnySHA1InWant , qui permet à upload-pack d’accepter une requête de fetch qui demande n’importe quel object. (La valeur par défaut est false ).

Voir commit f8edeaa (nov. 2016, Git v2.11.1) par David “novalis” Turner ( novalis ) :

upload-pack : permet éventuellement de récupérer n’importe quel fichier sha1

Il semble un peu idiot de faire une vérification de la crédibilité dans le cas où l’on fait confiance à l’utilisateur pour accéder à tout dans le référentiel.

En outre, il est un système dur dans un système dissortingbué – peut-être un serveur annonce-t-il une ref, mais un autre a depuis forcé cette ref et peut-être que les deux requêtes HTTP sont dirigées vers ces différents serveurs.

Vous ne clonez qu’une seule fois, donc si vous avez déjà un clone du référentiel distant, le retirer ne sera plus tout télécharger. Indiquez simplement quelle twig vous souhaitez extraire, ou récupérez les modifications et récupérez la validation souhaitée.

Récupérer à partir d’un nouveau référentiel est très peu coûteux en bande passante, car il ne télécharge que les modifications que vous n’avez pas. Pensez en termes de Git à prendre les bonnes décisions, avec une charge minimale.

Git stocke tout dans le dossier .git . Un commit ne peut pas être récupéré et stocké de manière isolée, il a besoin de tous ses ancêtres. Ils sont interdépendants .

Pour réduire la taille du téléchargement, vous pouvez toutefois demander à git de ne récupérer que les objects liés à une twig ou à une validation spécifique:

 git fetch origin refs/heads/branch:refs/remotes/origin/branch 

Cela ne téléchargera que les commits contenus dans la twig de la branch distante (et seulement ceux que vous manquez) , et les stockera dans l’ origin/branch . Vous pouvez alors fusionner ou valider.

Vous pouvez également spécifier uniquement une validation SHA1:

 git fetch origin 96de5297df870:refs/remotes/origin/foo-commit 

Cela ne télécharge que la validation du SHA-1 96de5297df870 spécifié (et de ses ancêtres manquants), et la stocke comme origin/foo-commit (non existante).

J’ai tiré sur mon repo git:

 git pull --rebase   

Permettre à git de récupérer tout le code pour la twig et ensuite je suis allé faire une remise sur le commit qui m’intéressait.

git reset --hard

J’espère que cela t’aides.

Vous pouvez simplement récupérer un seul commit d’un repo distant avec

 git fetch   

où,

• peut être un nom de repo distant (par exemple, origin ) ou même une URL repo distante (par exemple, https://git.foo.com/myrepo.git )
• peut être la validation SHA1

par exemple

 git fetch https://git.foo.com/myrepo.git 0a071603d87e0b89738599c160583a19a6d95545 

après avoir récupéré le commit (et les ancêtres manquants), vous pouvez simplement le récupérer avec

 git checkout FETCH_HEAD 

Notez que cela vous amènera dans l’état “tête détachée”.

Vous pouvez simplement récupérer le repo distant avec:

 git fetch  

où,

• peut être un nom de repo distant (par exemple, origin ) ou même une URL repo distante (par exemple https://git.foo.com/myrepo.git )

par exemple:

 git fetch https://git.foo.com/myrepo.git 

Après avoir récupéré les mises en pension, vous pouvez fusionner les validations souhaitées (puisque la question concerne l’extraction d’une validation, fusionner plutôt vous pouvez utiliser une sélection par sélection).

 git merge  

• peut être la validation SHA1

par exemple:

 git cherry-pick 0a071603d87e0b89738599c160583a19a6d95545 

ou

 git merge 0a071603d87e0b89738599c160583a19a6d95545 

Si est la dernière validation que vous souhaitez fusionner, vous pouvez également utiliser la variable FETCH_HEAD:

 git cherry-pick (or merge) FETCH_HEAD 

Je pense que «git ls-remote» ( http://git-scm.com/docs/git-ls-remote ) devrait faire ce que vous voulez. Sans force chercher ou tirer.

Enfin, j’ai trouvé un moyen de cloner un commit spécifique en utilisant git cherry-pick . En supposant que vous ne disposez d’aucun référentiel en local et que vous récupérez des validations spécifiques à distance,

1) créer un référentiel vide dans local et git init

2) git remote add origine ” url-of-repository ”

3) git fetch origin [cela ne déplacera pas vos fichiers vers votre espace de travail local à moins que vous ne fusionniez]

4) git cherry-pick ” Entrez-long-commit-hash-that-you-need ”

Done.This, vous n’aurez que les fichiers de ce commit spécifique dans votre local.

Enter-long-commit-hash:

Vous pouvez obtenir ceci en utilisant -> git log –pretty = oneline