¿& # 8220; git fetch --tags & # 8221; incluye & # 8220; git fetch & # 8221 ;?

https://stackoverflow.com/questions/1204190

05-07-2019
|

Pregunta

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

I.e. si ejecuto git fetch --tags , ¿hay alguna razón para ejecutar inmediatamente git fetch directamente después?

¿Qué pasa con git pull y git pull --tags ? ¿La misma situación?

Solución

Nota: a partir de (Q1 2014) , git fetch --tags obtiene las etiquetas además de que se encuentran en la misma línea de comandos sin la opción.

Consulte commit c5a84e9 por Michael Haggerty (mhagger) :

Anteriormente, fetch " --tags " La opción se consideró equivalente a especificar la refspec
refs/tags/*:refs/tags/*
en la línea de comando;   en particular, hizo que se ignorara la configuración del remoto. < name > .refspec .

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

Si un usuario desea obtener etiquetas solo , aún es posible especificar un refspec explícito:
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 de " fetch --tags " comportamiento.
   Commit f0cb2f1 (2012-12-14) fetch --tags > hizo que la documentación coincida 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 todas las etiquetas se obtengan desde el control remoto además de cualquier otra cosa que se esté recuperando .

Desde Git 2.5 (Q2 2015) git pull --tags es más sólido:

Consulte commit 19d122b por Paul Tan ( pyokagan ) , 13 de mayo de 2015.
^{(Combinado por Junio ??C Hamano - gitster - en commit cc77b99 , 22 de mayo de 2015)}

pull : elimina el error --tags en el caso de no combinar candidatos

Desde 441ed41 ( git pull --tags " ;: error con un mejor mensaje.,   2007-12-28, Git 1.5.4+), git pull --tags imprimiría un mensaje de error diferente si    git-fetch no devolvió ningún candidato de combinació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 --tags anularía cualquier   configuró refspecs, y por lo tanto no habría candidatos de fusión. Por lo tanto, el mensaje de error se introdujo para evitar confusiones.

Sin embargo, desde c5a84e9 ( fetch --tags : obtener etiquetas además de   otra cosa, 2013-10-30, Git 1.9.0+), git fetch --tags obtendría etiquetas además   a cualquier refspecs configurado.
  Por lo tanto, si se produce una situación sin candidatos de combinación, no es porque se estableció --tags . 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 fetch es más rápido.

Consulte commit 5827a03 (13 oct 2016) por Jeff King ( peff ) .
^{(Combinado por Junio ??C Hamano - gitster - en commit 9fcd144 , 26 oct 2016)}

fetch : use " quick " has_sha1_a_f_1_file_control>
Cuando buscamos en un control remoto que tiene muchas etiquetas que son irrelevantes para las ramas que seguimos, solíamos perder demasiados ciclos al verificar si el objeto al que apunta una etiqueta (¡que no vamos a buscar!) existe en nuestro repositorio con mucho cuidado. Este parche enseña a usar el método HAS_SHA1_QUICK para sacrificar precisión en la velocidad, en los casos en que podamos ser exigentes con un Repack simultáneo. Estos son los resultados del script de perf incluido, que configura 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 solo para una situación en la que: 


  
   Tiene muchos paquetes en el lado del cliente para hacer que  reprepare_packed_git ()  sea costoso (la parte más costosa es encontrar duplicados en una lista sin clasificar, que actualmente es cuadrática). 
   Necesita un gran número 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 activa una re-lectura del directorio del paquete. 
   En circunstancias normales, el cliente seguiría esas etiquetas automáticamente y después de una búsqueda grande, (2) ya no sería cierto. 

  Pero si esas etiquetas apuntan a un historial que está desconectado de lo que el cliente obtiene de otra manera, entonces nunca lo seguirá automáticamente, y esos candidatos lo impactarán en cada búsqueda.

 Git 2.21 (febrero de 2019) parece haber introducido una regresión cuando  config  remote.origin.fetch  es  no  el predeterminado  ( '+ refs / heads / *: refs / remotes / origin / *' ) 

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



	
					
			
			


	
			


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

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


  git fetch  recupera todos los encabezados de sucursal (o todos 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 ramificaciones. En la mayoría de los casos, todas las etiquetas son accesibles de esta manera. 
  git fetch --tags  busca todas las etiquetas, todas las confirmaciones necesarias para ellas.  no  actualizará los encabezados de las sucursales, incluso si son accesibles desde las etiquetas que se buscaron. 


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

 Tampoco es " dos veces más lento " a menos que te refieras en términos de escribir en la línea de comandos, en cuyo caso los alias resuelven tu problema. Básicamente, no hay gastos generales al realizar las dos solicitudes, ya que solicitan información diferente. 
	


	
		
	
	
			 Voy a responder esto yo mismo. 

 He determinado que hay una diferencia. " git fetch --tags " ¡podría traer todas las etiquetas, pero no trae ningún nuevo compromiso! 

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

$ git fetch --tags
$ git fetch


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


	
		
	
	
			 El problema general aquí es que  git fetch  buscará  + refs / heads / *: refs / remotes / $ remote / * . Si alguna de estas confirmaciones tiene etiquetas, esas etiquetas también se buscarán. Sin embargo, si hay etiquetas a las que no puede acceder ninguna rama en el control remoto, no se recuperarán. 

 La opción  --tags  cambia la refspec a  + refs / tags / *: refs / tags / * . Usted  podría  pedir  git fetch  para agarrar ambos. Estoy bastante seguro de que solo hago un  git fetch & amp; & amp; git fetch -t  usaría el siguiente comando: 

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


 Y si desea que esto sea el predeterminado para este repositorio, puede agregar un segundo refspec a la recuperación predeterminada: 

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


 Esto agregará una segunda línea  fetch =  en el  .git / config  para este control remoto. 



 Pasé un rato 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 todos los encabezados y etiquetas del control remoto, así que use refspec refs/*:refs/* 
 Sobrescribe las ramas y etiquetas locales con  +  sin avance rápido antes de la refspec 
 Sobrescriba la rama actualmente retirada si es necesario -u 
 Eliminar ramas y etiquetas que no están presentes en -p remoto 
 Y forzar para estar seguro de -f 
	


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

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

  git pull , por supuesto, no es más que un envoltorio para un  git fetch < thisrefspec > ;; git merge . Se recomienda que se acostumbre a hacer  git fetch  y  git merge  manualmente antes de dar el salto a  git pull  simplemente porque le ayuda entienda lo que  git pull  está haciendo en primer lugar. 

 Dicho esto, la relación es exactamente la misma que con  git fetch .  git pull  es 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. 
	

			
		
			


	
		
			Licenciado bajo: CC-BY-SA con atribución
			No afiliado a StackOverflow

¿& # 8220; git fetch --tags & # 8221; incluye & # 8220; git fetch & # 8221 ;?

`pull` : elimina el error `--tags` en el caso de no combinar candidatos

`fetch` : use " quick " `has_sha1_a_f_1_file_control>`

¿& # 8220; git fetch --tags & # 8221; incluye & # 8220; git fetch & # 8221 ;?

pull : elimina el error --tags en el caso de no combinar candidatos

fetch : use " quick " has_sha1_a_f_1_file_control>

`pull` : elimina el error `--tags` en el caso de no combinar candidatos

`fetch` : use " quick " `has_sha1_a_f_1_file_control>`