¿"Git fetch --tags" incluye "git fetch"?

Una pregunta agradable y simple: ¿es la función de "git fetch" un subconjunto estricto de git fetch --tags?

Es decir, si corro git fetch --tags, ¿hay alguna razón para correr git fetchinmediatamente después?

¿Qué hay de git pully git pull --tags? ¿Misma situacion?

Nota: comenzando con git 1.9 / 2.0 (Q1 2014) , git fetch --tagsobtiene etiquetas además de las obtenidas por la misma línea de comando sin la opción.

Ver commit c5a84e9 por Michael Haggerty (mhagger) :

Anteriormente, la --tagsopción " " de búsqueda se consideraba equivalente a especificar la especificación de referencia

refs/tags/*:refs/tags/*

en la línea de comando; en particular, hizo remote.<name>.refspecque se ignorara la configuración.

Pero no es muy útil buscar etiquetas sin también buscar otras referencias, mientras que es bastante útil poder obtener etiquetas además de otras referencias.
Así que cambie la semántica de esta opción para hacer la última.

Si un usuario desea obtener solo etiquetas, aún es posible especificar una especificación de referencia explícita:

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

Tenga en cuenta que la documentación anterior a 1.8.0.3 era ambigua sobre este aspecto del " fetch --tags" comportamiento.
Commit f0cb2f1 (2012-12-14) fetch --tagshizo que la documentación coincida con el comportamiento anterior.
Esta confirmación cambia la documentación para que coincida con el nuevo comportamiento (ver Documentation/fetch-options.txt).

Solicite que todas las etiquetas se obtengan del control remoto además de cualquier otra cosa que se obtenga .

Dado que Git 2.5 (Q2 2015) git pull --tagses más robusto:

Ver commit 19d122b por Paul Tan ( pyokagan) , 13 de mayo de 2015.
^{(Fusión por Junio ​​C Hamano - gitster- en commit cc77b99 , 22 de mayo de 2015)}

pull: eliminar --tagserror en caso de candidatos no fusionados

Dado que 441ed41 (" git pull --tags": error con un mensaje mejor., 28/12/2007, Git 1.5.4+), git pull --tagsimprimiría un mensaje de error diferente si git-fetchno devuelve ningún candidato de fusión:

It doesn't make sense to pull all tags; you probably meant:
       git fetch --tags

Esto se debe a que, en ese momento, git-fetch --tagsanularía cualquier especificación de referencia configurada y, por lo tanto, no habría candidatos para la fusión. El mensaje de error se introdujo así para evitar confusiones.

Sin embargo, desde c5a84e9 ( fetch --tags: buscar etiquetas además de otras cosas, 2013-10-30, Git 1.9.0+), git fetch --tagsbuscaría etiquetas además de cualquier refspecs configurado.
Por lo tanto, si ocurre una situación de candidatos sin fusión, no es porque --tagsse estableció. Como tal, este mensaje de error especial ahora es irrelevante.

Para evitar confusiones, elimine este mensaje de error.

Con Git 2.11+ (Q4 2016) git fetches más rápido.

Ver commit 5827a03 (13 de octubre de 2016) por Jeff King ( peff) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 9fcd144 , 26 oct 2016)}

fetch: utilice "rápido" has_sha1_filepara seguir la etiqueta

Al buscar desde un control remoto que tiene muchas etiquetas que son irrelevantes para las ramas que estamos siguiendo, solíamos desperdiciar demasiados ciclos al verificar si el objeto señalado por una etiqueta (¡que no vamos a buscar!) Existe en nuestro repositorio con mucho cuidado

Este parche enseña a fetch a usar HAS_SHA1_QUICK para sacrificar la precisión por la velocidad, en los casos en que podríamos ser rápidos con un reempaque simultáneo.

Estos son los resultados del script de perf incluido, que establece una situación similar a la descrita anteriormente:

Test            HEAD^               HEAD
----------------------------------------------------------
5550.4: fetch   11.21(10.42+0.78)   0.08(0.04+0.02) -99.3%

Eso solo se aplica a una situación en la que:

1. Tiene muchos paquetes en el lado del cliente para hacer que sea reprepare_packed_git()costoso (la parte más costosa es encontrar duplicados en una lista sin clasificar, que actualmente es cuadrática).
2. Necesita una gran cantidad de referencias de etiquetas en el lado del servidor que sean candidatos para el seguimiento automático (es decir, que el cliente no tiene). Cada uno desencadena una relectura del directorio del paquete.
3. En circunstancias normales, el cliente seguiría automáticamente esas etiquetas y después de una búsqueda grande, (2) ya no sería cierto.
   Pero si esas etiquetas apuntan al historial que está desconectado de lo que el cliente obtiene, entonces nunca se seguirá automáticamente, y esos candidatos lo afectarán en cada búsqueda.

Git 2.21 (febrero de 2019) parece haber introducido una regresión cuando la configuración noremote.origin.fetch es la predeterminada ( '+refs/heads/*:refs/remotes/origin/*')

fatal: multiple updates for ref 'refs/tags/v1.0.0' not allowed

Git 2.24 (Q4 2019) agrega otra optimización.

Ver commit b7e2d8b (15 sep 2019) por Masaya Suzuki ( draftcode) .
^{(Fusionada por Junio ​​C Hamano - gitster- en commit 1d8b0df , 07 oct 2019)}

fetch: use oidsetpara mantener los OID deseados para una búsqueda más rápida

Durante git fetch, el cliente comprueba si los OID de las etiquetas anunciadas ya están en el conjunto de OID deseado de la solicitud de búsqueda.
Esta verificación se realiza en un escaneo lineal.
Para un repositorio que tiene muchas referencias, repetir este análisis lleva más de 15 minutos.

Para acelerar esto, cree un oid_setOID para otras referencias.

Nota: esta respuesta solo es válida para git v1.8 y anteriores.

La mayor parte de esto se ha dicho en las otras respuestas y comentarios, pero aquí hay una explicación concisa:

• git fetchrecupera todos los encabezados de rama (o todos los especificados por la opción de configuración remote.fetch), todas las confirmaciones necesarias para ellos y todas las etiquetas a las que se puede acceder desde estas ramas. En la mayoría de los casos, todas las etiquetas son accesibles de esta manera.
• git fetch --tagsrecupera todas las etiquetas, todas las confirmaciones necesarias para ellas. Será no actualizar directores de las sucursales, incluso si son accesibles desde las etiquetas que eran descabellada.

Resumen: si realmente desea estar totalmente actualizado, utilizando solo fetch, debe hacer ambas cosas.

Tampoco es "el doble de lento" a menos que se refiera a escribir en la línea de comandos, en cuyo caso los alias resuelven su problema. Esencialmente no hay gastos generales al hacer las dos solicitudes, ya que están solicitando información diferente.

Voy a responder esto yo mismo.

He determinado que hay una diferencia. "git fetch --tags" puede traer todas las etiquetas, ¡pero no trae nuevos commits!

Resulta que uno tiene que hacer esto para estar totalmente "actualizado", es decir, replicar un "git pull" sin la fusión:

$ git fetch --tags
$ git fetch

Es una pena, porque es el doble de lento. Si solo "git fetch" tuviera la opción de hacer lo que normalmente hace y traer todas las etiquetas.

El problema general aquí es que git fetchbuscará +refs/heads/*:refs/remotes/$remote/*. Si alguno de estos commits tiene etiquetas, esas etiquetas también se recuperarán. Sin embargo, si hay ramas a las que ninguna rama en el control remoto pueda acceder, no se recuperarán.

La --tagsopción cambia la especificación de referencia a +refs/tags/*:refs/tags/*. Usted podría pedir git fetcha agarrar ambos. Estoy bastante seguro de que solo haría un git fetch && git fetch -tusaría el siguiente comando:

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

Y si desea hacer que esto sea el predeterminado para este repositorio, puede agregar una segunda especificación de referencia a la búsqueda predeterminada:

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

Esto agregará una segunda fetch =línea .git/configpara este control remoto.

Pasé un tiempo buscando la manera de manejar esto para un proyecto. Esto es lo que se me ocurrió.

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

En mi caso quería estas características

• Tome todas las cabezas y etiquetas del control remoto, así que use refspec refs/*:refs/*
• Sobrescribir ramas y etiquetas locales con avance no rápido +antes de la especificación de referencia
• Sobrescribir la rama actualmente desprotegida si es necesario -u
• Eliminar ramas y etiquetas no presentes en el control remoto -p
• Y obligar a estar seguro -f

En la mayoría de las situaciones, git fetchdebe hacer lo que quiera, que es 'obtener algo nuevo del repositorio remoto y ponerlo en su copia local sin fusionarse con sus sucursales locales'. git fetch --tagshace exactamente eso, excepto que no obtiene nada excepto nuevas etiquetas.

En ese sentido, git fetch --tagsde ninguna manera es un superconjunto de git fetch. De hecho, es exactamente lo contrario.

git pull, por supuesto, no es más que una envoltura para a git fetch <thisrefspec>; git merge. Se recomienda que uno se acostumbra a hacer manual de git fetchING y git mergeing antes de hacer el salto a git pullsimplemente porque ayuda a entender lo que git pullestá haciendo en primer lugar.

Dicho esto, la relación es exactamente la misma que con git fetch. git pulles el superconjunto de git pull --tags.

git fetch upstream --tags

funciona bien, solo obtendrá nuevas etiquetas y no obtendrá ninguna otra base de código.