Fait « git fetch--tags » inclure « git fetch » ?

Question

Une question simple et agréable - est la fonction de « git fetch » un sous-ensemble strict de `` ?

C'est-à-dire que si je lance , y a-t-il toujours une raison pour exécuter immédiatement tout droit par la suite ?

Qu’en est-il et ? Même situation ?

Answer 1

Remarque: à partir de git 1.9/2.0 (T1 2014), git fetch --tags extrait des balises en plus ce sont extraites par la même ligne de commande sans l'option.

Voir commettre c5a84e9 par Michael Haggerty (mhagger):

Auparavant, il récupère les "--tags" option a été considérée comme équivalente à la spécification de la refspec

refs/tags/*:refs/tags/*

sur la ligne de commande; en particulier, il a provoqué l' remote.<name>.refspec configuration pour être ignoré.

Mais il n'est pas très utile pour aller chercher des balises sans aller chercher d'autres références, alors qu'il est très utile d'être en mesure d'aller chercher des balises en plus d'autres références.
Afin de modifier la sémantique de cette option pour la deuxième solution.

Si un utilisateur souhaite récupérer uniquement les balises, puis il est encore possible de spécifier explicitement refspec:

git fetch <remote> 'refs/tags/*:refs/tags/*'

Veuillez noter que la documentation avant 1.8.0.3 était ambiguë à propos de cet aspect de "fetch --tags" de comportement.
S'engager f0cb2f1 (2012-12-14) fetch --tags fait à la documentation correspondre à l'ancien comportement.
Ce commit des modifications de la documentation afin de correspondre au nouveau comportement (voir Documentation/fetch-options.txt).

Demande que toutes les balises être récupérées à partir de la télécommande en plus de tout ce qui est récupérée.

Answer 2

La plupart de ce qui a été dit dans les autres réponses et commentaires, mais voici une explication concise:

• git fetch extrait tous les chefs de direction (ou tous spécifié par la télécommande.chercher de l'option de configuration), les validations nécessaires, et toutes les balises qui sont accessibles à partir de ces branches. Dans la plupart des cas, toutes les balises sont accessibles de cette manière.
• git fetch --tags récupère toutes les balises, les validations nécessaires. Il va pas mettre à jour les chefs de direction, même si ils sont accessibles depuis les balises qui ont été récupérés.

Résumé: Si vous voulez vraiment être totalement à jour, en utilisant uniquement les récupérer, vous devez faire les deux.

C'est aussi à ne pas "deux fois plus lent", à moins que tu veux dire en termes de taper sur la ligne de commande, auquel cas les alias de résoudre votre problème. Il n'y a pratiquement pas de frais généraux en faire les deux demandes, car ils demandent des informations différentes.

Answer 3

Je vais répondre moi-même.

J’ai déterminé qu’il y a une différence. « git fetch--tags » pourrait apporter dans toutes les balises, mais il n’apporte pas dans n’importe quel nouveau commet !

Il s’avère que l’un doit faire cela pour être totalement « à jour », c'est-à-dire reproduit un « git pull » sans la fusion :

C’est une honte, parce que c’est deux fois plus lente. Si seulement « git fetch » avait une option pour faire ce qu’il fait normalement et apporter toutes les balises.

Answer 4

Le grand problème ici est que, git fetch va récupérer refs/heads/*:refs/remotes/$remote/*. Si l'un de ces révisions ont des étiquettes, ces étiquettes seront également récupérées. Cependant, si il y a des balises pas accessible par n'importe quelle branche sur la télé, ils ne seront pas récupérés.

L' --tags option active la refspec d' +refs/tags/*:refs/tags/*. Vous pourriez demandez git fetch de saisir à la fois. Je suis assez sûr de faire juste un git fetch && git fetch -t il vous suffit d'utiliser la commande suivante:

git fetch origin refs/heads/*:refs/remotes/origin/* +refs/tags/*:refs/tags/*

Et si vous souhaitez rendre cette valeur par défaut pour ce repo, vous pouvez ajouter un deuxième refspec à la valeur par défaut fetch:

git config --local --add remote.origin.fetch +refs/tags/*:refs/tags/*

Cela va ajouter un deuxième fetch = ligne dans l' .git/config de cette distance.

---

J'ai passé un certain temps à la recherche de la façon de gérer cela pour un projet. C'est ce que je suis venu avec.

git fetch -fup origin +refs/*:refs/*

Dans mon cas, je voulais que ces caractéristiques

• Prenez tous les chefs et les balises de la télécommande pour utiliser refspec refs/*:refs/*
• Écraser les locaux de branches et de tags avec les fast-forward + avant la refspec
• Remplacer extrait de la succursale si nécessaire, -u
• Supprimer des branches et des tags n'est pas présent dans éloignées -p
• Et de la force pour être sûr de l' -f

Answer 5

Dans la plupart des situations, git fetch devrait faire ce que vous voulez, ce qui est "d'obtenir quelque chose de nouveau sur le dépôt distant et de le mettre dans votre copie locale sans la fusion de vos branches locales'. git fetch --tags fait exactement ça, sauf que il ne peut pas faire n'importe quoi sauf de nouvelles balises.

En ce sens, git fetch --tags n'est en aucune façon un sur-ensemble de l' git fetch. C'est en fait exactement le contraire.

git pull, bien sûr, n'est rien, mais un wrapper pour un git fetch <thisrefspec>; git merge. Il est recommandé que vous obtenez utilisé pour faire de manuel git fetching et git mergeing avant de faire le saut en git pull tout simplement parce qu'il vous aide à comprendre ce qu' git pull est de le faire en premier lieu.

Cela étant dit, la relation est exactement le même que git fetch. git pull est le sur-ensemble de l' git pull --tags.