Différences entre git remote update et fetch?

Est-ce git remote updatel'équivalent de git fetch?

MISE À JOUR: plus d'informations!

J'aurais dû le faire depuis le début: j'ai greffé les notes de publication de Git dans le dépôt Git de Git (donc méta!)

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

Ensuite, j'ai fait une lessrecherche pour --all, et c'est ce que j'ai trouvé dans les notes de publication de Git version 1.6.6 :

git fetchappris --allet --multipleoptions, pour exécuter l'extraction à partir de nombreux référentiels, et --pruneoption pour supprimer les branches de suivi à distance qui sont devenues obsolètes. Celles-ci rendent git remote updateet git remote prunemoins nécessaires (il n'y a pas de plan de suppression remote updateni remote prune, cependant).

La version 1.6.6 n'est sortie que le 23 décembre 2009 et l'affiche originale a posé sa question le 6 décembre 2009.

Ainsi, comme vous pouvez le voir dans les notes de publication, les auteurs de Git étaient conscients du fait que la git remote updatefonctionnalité de commande était quelque peu dupliquée par git fetch, mais ils ont décidé de ne pas la supprimer, peut-être pour des raisons de compatibilité avec les scripts et programmes existants, ou peut-être parce que c'est tout simplement trop de travail et 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, et Git a traversé plusieurs versions depuis lors (il est passé de la v1.6.5.5 à la v1.8.3.2 au moment d'écrire ces lignes), et en regardant la documentation actuelle pour git remote updateet git fetch, il semble comme ils peuvent tous les deux effectuer fondamentalement la même fonction de récupérer de nouveaux commits à partir de plusieurs télécommandes , avec les bonnes options et arguments.

Récupération de toutes les télécommandes

Une façon de récupérer plusieurs télécommandes consiste à utiliser le --alldrapeau:

git fetch --all

Cela récupérera toutes vos télécommandes configurées, en supposant que vous ne les ayez pas remote.<name>.skipFetchAllconfigurées:

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 git-config

Cela équivaudrait à utiliser

git remote update

sans spécifier de groupe distant à récupérer, et aussi ne pas avoir remotes.defaultdéfini dans votre configuration de dépôt, et aussi qu'aucune de vos télécommandes n'a remote.<name>.skipDefaultUpdatedéfini sur true.

La documentation 1.8.3.2 actuelle pour la configuration de Git ne mentionne pas le remotes.defaultparamètre, mais j'ai consulté The Almighty Google à ce sujet et j'ai 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 updatecommande. Il peut s'agir de télécommandes de vos coéquipiers, de membres de la communauté de confiance d'un projet Open Source ou similaire.

Donc, vraisemblablement, si vous l'avez remotes.defaultdéfini, et que toutes vos télécommandes ne sont pas répertoriées dans celui-ci, git remote updateelles ne récupèrent pas toutes les télécommandes dont votre dépôt est "conscient".

En ce qui concerne le remote.<name>.skipDefaultUpdateparamètre, la documentation Git l' explique 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ération d'un groupe spécifié de télécommandes

Au lieu de récupérer toutes les télécommandes, les deux fetchet remote updatevous permettent de spécifier plusieurs télécommandes et groupes de télécommandes à récupérer:

git fetch [<options>] <group>
git fetch --multiple [<options>] [(<repository> | <group>)…]

git fetch [<options>] <group>vous permet de récupérer plusieurs télécommandes faisant partie d'un groupe (pour emprunter un autre exemple à Mislav ):

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

git fetch --multiplevous permet de spécifier plusieurs référentiels et groupes de référentiels à récupérer à la fois (à partir de la documentation ):

Autoriser plusieurs <repository>et <group>arguments à préciser. Non <refspec>speut être spécifié.

Ambiguïté dans la git remote updatedocumentation

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

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

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

Cependant, dans le même document, l'explication de la updatecommande ne dit rien sur la spécification de plusieurs arguments de groupe et distants, seulement qu'elle

Récupérez [es] mises à jour pour un ensemble nommé de télécommandes dans le référentiel tel que défini par remotes.<group>.

Il n'est donc pas clair si cela git remote updatefonctionne de la même manière en git fetch --multiplece 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 cas simple de récupérer une seule télécommande:

git fetch <remote>

Il se peut que vous puissiez également utiliser

git remote update <remote>

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

Emballer

Comme je l'ai expliqué, git fetchet git remote updatese comportent de la même manière en ce qui concerne la récupération à partir de plusieurs télécommandes. Ils partagent une syntaxe et des arguments similaires, bien quegit fetch soient plus courts, de sorte que les gens les trouvent probablement plus faciles à taper et à utiliser.

Cela peut être le cas qui git remote updatene peut pas être utilisé pour récupérer une seule télécommande comme avec git fetch, mais comme je l'ai souligné, la documentation ne le précise pas.

De côté

La duplication des fonctionnalités entre les commandes de porcelaine Git, illustrée par git fetchet git remote updateci - dessus, n'est pas unique. J'ai remarqué une situation similaire avec git rebase --ontoet git cherry-pick, en ce sens que les deux peuvent prendre une gamme de commits pour se patcher sur un nouveau commit de base.

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

git cherry-pickappris à choisir une gamme de commits (par exemple cherry-pick A..Bet cherry-pick --stdin), ainsi fait git revert; cependant, ceux-ci ne prennent pas en charge le meilleur contrôle de séquençage rebase [-i].

Oui et non. git remote updaterécupère toutes les télécommandes, pas une seule.

Sans regarder le code pour voir si remote updatec'est juste un script shell (possible), il exécute essentiellement fetch pour chaque télécommande. git fetchpeut être beaucoup plus granulaire.