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

Nota: a partir de git 1.9/2.0 (primer trimestre de 2014) , git fetch --tagsrecupera etiquetas además de las que se obtienen mediante la misma línea de comando sin la opción.

Para recuperar solo etiquetas:

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

En detalles:

Ver el compromiso c5a84e9 de Michael Haggerty (mhagger) :

Anteriormente, la opción " " de buscar --tagsse consideraba equivalente a especificar la especificación de referencia.

refs/tags/*:refs/tags/*

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

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

Si un usuario desea recuperar 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.
La confirmación f0cb2f1 (14 de diciembre de 2012) fetch --tagshizo que la documentación coincidiera con el comportamiento anterior.
Esta confirmación cambia la documentación para que coincida con el nuevo comportamiento (consulte Documentation/fetch-options.txt).

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

Dado que Git 2.5 (segundo trimestre de 2015) git pull --tagses más sólido:

Véase el compromiso 19d122b de Paul Tan ( pyokagan) , 13 de mayo de 2015.
^{(Fusionado por Junio ​​C Hamano -- gitster-- en el compromiso cc77b99 , 22 de mayo de 2015)}

pull: elimina --tagsel error en el caso de que no se fusionen candidatos

Desde 441ed41 (" git pull --tags": error con un mensaje mejor., 2007-12-28, Git 1.5.4+), git pull --tagsimprimiría un mensaje de error diferente si git-fetchno devolviera 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. Por tanto, se introdujo el mensaje de error para evitar confusiones.

Sin embargo, dado que 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 especificación de referencia configurada.
Por lo tanto, si se produce alguna situación en la que no hay candidatos para la fusión, no es porque --tagsestuviera establecida. Como tal, este mensaje de error especial ahora es irrelevante.

Para evitar confusiones, elimine este mensaje de error.

Con Git 2.11+ (cuarto trimestre de 2016) git fetches más rápido.

Véase el compromiso 5827a03 (13 de octubre de 2016) de Jeff King ( peff) .
^{(Fusionado por Junio ​​C Hamano -- gitster-- en la confirmación 9fcd144 , 26 de octubre de 2016)}

fetch: use "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. demasiado cuidadosamente.

Este parche enseña a buscar a usar HAS_SHA1_QUICK para sacrificar la precisión por la velocidad, en los casos en los que podamos ser atrevidos con un reempaquetado simultáneo.

A continuación se muestran los resultados del script de rendimiento 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 se aplica sólo para una situación en la que:

1. Tienes muchos paquetes en el lado del cliente para encarecerlos reprepare_packed_git()(la parte más cara es encontrar duplicados en una lista sin ordenar, que actualmente es cuadrática).
2. Necesita una gran cantidad de referencias de etiquetas en el lado del servidor que sean candidatas para el seguimiento automático (es decir, que el cliente no tenga). 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 cierta.
   Pero si esas etiquetas apuntan a un historial que está desconectado de lo que el cliente obtiene, entonces nunca realizará un seguimiento automático 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 (cuarto trimestre de 2019) agrega otra optimización.

Ver el compromiso b7e2d8b (15 de septiembre de 2019) de Masaya Suzuki ( draftcode) .
^{(Fusionado por Junio ​​C Hamano -- gitster-- en commit 1d8b0df , 7 de octubre de 2019)}

fetch: utilícelo oidsetpara conservar 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 recuperación.
Esta verificación se realiza en un escaneo lineal.
Para un repositorio que tiene muchas referencias, repetir este escaneo lleva más de 15 minutos.

Para acelerar esto, cree un oid_setOID para los otros árbitros.

Dec 16 '2013 10:12 VonC