Différences entre la mise à jour à distance de git et la récupération?

Est-ce que git remote update est l’équivalent de git fetch ?

MISE À JOUR: plus d’informations!

J’aurais dû le faire depuis le début: j’ai accepté les notes de sortie de Git dans le repository Git de Git (donc méta!)

 grep --color=always -R -C30 fetch Documentation/RelNotes/* | less 

Ensuite, j’ai less cherché --all , et c’est ce que j’ai trouvé dans les notes de version de Git version 1.6.6 :

git fetch --multiple options apsockets --all et --multiple , pour lancer l’extraction de nombreux référentiels et l’option --prune pour supprimer les twigs de suivi distantes obsolètes. Celles-ci rendent git remote update et git remote prune moins nécessaire (il n’est pas prévu de supprimer remote update remote prune ni remote prune , cependant).

La version 1.6.6 n’a pas été publiée avant le 23 décembre 2009 et l’affiche originale posait sa question le 6 décembre 2009.

Comme vous pouvez le voir dans les notes de version, les auteurs de Git étaient conscients que la fonctionnalité de commande de git remote update était quelque peu dupliquée par git fetch , mais ils ont décidé de ne pas la supprimer. programmes, ou peut-être parce que c’est trop de travail et qu’il y a des éléments prioritaires.


Réponse originale avec plus de détails

La réponse de xenoterracide a maintenant 3,5 ans maintenant, et Git a passé par plusieurs versions depuis (il est passé de la v1.6.5.5 à la v1.8.3.2 à la date d’écriture) et examine la documentation actuelle de git remote update git fetch , on dirait qu’ils peuvent tous deux exécuter fondamentalement la même fonction d’extraction de nouveaux commits à partir de plusieurs télécommandes , avec les bonnes options et les bons arguments.

Récupérer toutes les télécommandes

Une façon de récupérer plusieurs télécommandes est d’ --all drapeau --all :

 git fetch --all 

Cela va chercher à partir de toutes vos télécommandes configurées, en supposant que vous n’avez pas de remote..skipFetchAll défini pour eux:

Si true, cette télécommande sera ignorée par défaut lors de la mise à jour à l’aide de git-fetch (1) ou de la sous – commande update de git-remote (1) . – Documentation de git-config

Ce serait équivalent à utiliser

 git remote update 

sans spécifier de groupe distant à récupérer, et également à ne pas définir remotes.default dans votre configuration repo, et à ne pas avoir de télécommande sur vos télécommandes remote..skipDefaultUpdate défini sur true.

La documentation 1.8.3.2 actuelle pour la configuration de Git ne mentionne pas le paramètre remotes.default , mais j’ai consulté le tout-puissant Google à ce sujet et trouvé cette explication utile de Mislav Marohnić :

 $ git config remotes.default 'origin mislav staging' $ git remote update # fetches remotes "origin", "mislav", and "staging" 

Vous pouvez définir une liste par défaut de télécommandes à récupérer par la remote update . Celles-ci peuvent être des télécommandes de vos coéquipiers, des membres de la communauté de confiance d’un projet opensource, ou similaires.

Donc, vraisemblablement, si vous avez défini remotes.default , et que toutes vos télécommandes ne sont pas listées, alors git remote update ne récupérera pas toutes les télécommandes dont votre référentiel est “conscient”.

En ce qui concerne le paramètre remote..skipDefaultUpdate , les documents Git l’ expliquent ainsi:

Si true, cette télécommande sera ignorée par défaut lors de la mise à jour à l’aide de git-fetch (1) ou de la sous – commande update de git-remote (1) .

Récupérer un groupe de télécommandes spécifié

Au lieu de récupérer toutes les télécommandes, à la fois fetch et remote update vous permettent de spécifier plusieurs télécommandes et groupes de télécommandes à récupérer:

 git fetch []  git fetch --multiple [] [( | )…] 

git fetch [] permet de récupérer plusieurs télécommandes appartenant à un groupe (pour reprendre un autre exemple de Mislav ):

 $ git config remotes.mygroup 'remote1 remote2 ...' $ git fetch mygroup 

git fetch --multiple permet de spécifier plusieurs référentiels et groupes de référentiels à récupérer (à partir des documents ):

Autoriser plusieurs arguments et à spécifier. Aucun s peut être spécifié.

Ambiguïté dans git remote update documentation de git remote update

Le synopsis pour git remote update spécifie que la syntaxe de la commande est la suivante:

 git remote [-v | --verbose] update [-p | --prune] [( | )…] 

Remarquez la dernière partie, [( | )…] ? Les points de fin ... impliquent que vous pouvez spécifier plusieurs groupes et télécommandes avec la commande, ce qui signifierait qu’il se comporte de la même manière que git fetch --multiple … voyez comment la syntaxe entre les deux est similaire?

Cependant, dans le même document, l’explication de la commande update ne dit rien sur la spécification de plusieurs arguments groupés et distants, mais seulement que

Récupère les mises à jour [es] pour un ensemble nommé de télécommandes dans le référentiel, comme défini par les remotes. .

Il est donc difficile de savoir si git remote update fonctionne de manière identique à git fetch --multiple en ce qui concerne la spécification de plusieurs télécommandes individuelles et de plusieurs groupes distants.

Récupérer une seule télécommande

Enfin, tout le monde connaît le simple cas de récupérer une seule télécommande:

 git fetch  

Ce pourrait être le cas que vous pouvez également utiliser

 git remote update  

pour faire la même chose, mais comme je l’ai mentionné dans la section précédente, la documentation de git remote update pas s’il est possible de récupérer autre chose qu’un groupe de télécommandes avec la commande.

Emballer

Comme je l’ai expliqué, git fetch et git remote update se comportent de la même manière en ce qui concerne l’extraction de plusieurs télécommandes. Ils partagent une syntaxe et des arguments similaires, bien que git fetch soit plus court, de sorte que les utilisateurs trouvent probablement plus facile à taper et à utiliser.

Il se peut que git remote update ne soit pas utilisée pour récupérer une seule télécommande comme avec git fetch , mais comme je l’ai souligné, la documentation ne le montre pas clairement.

De côté

La duplication des fonctionnalités entre les commandes en porcelaine de Git, illustrée par git fetch et git remote update ci-dessus, n’est pas unique. J’ai remarqué une situation similaire avec git rebase --onto et git cherry-pick , dans la mesure où tous les deux peuvent prendre une série de validations sur un nouveau commit de base.

Je suppose que Git a évolué au fil des ans, certaines fonctionnalités ont été (inévitablement?) Dupliquées, peut-être parfois comme une commodité pour les utilisateurs finaux (par exemple, il est plus simple de passer une gamme à cherry-pick que de passer un seul commit). encore et encore pour choisir une gamme). Apparemment, cherry-pick n’a pas toujours accepté toute une gamme de commits, comme expliqué dans les notes de la version 1.7.2 :

git cherry-pick appris à choisir une série de commits (par exemple, cherry-pick A..B et cherry-pick --stdin ), de même que git revert ; ceux-ci ne supportent pas le meilleur contrôle de séquençage rebase [-i] a, cependant.

Oui et non. git remote update partir de toutes les télécommandes, pas seulement une.

Sans regarder le code pour voir si remote update est juste un script shell (possible), elle s’exécute essentiellement pour chaque télécommande. git fetch peut être beaucoup plus granuleux.