git branch -r muestra diferentes repository compartido remoto en diferentes directorys locales de trabajo

Creé un repository compartido y luego lo cloné en dos carpetas (A y B). Todo en la misma PC.

Ahora hay dos twigs, master y v0 . La carpeta A y B ahora están en la twig v0 . En AI eliminó la twig v0 en el repository remoto.

 $ git push origin --delete v0 To file:///home/nanger/github/shanetworking1.git - [deleted] v0 

y luego traté de sacar el repository remoto tanto en A como en B (en la twig v0 ):

Ahora, veo eso

en un:

 $ git pull Already up-to-date. $ git branch -r origin/master $ git branch * master v0 

en B:

 $ git pull Already up-to-date $ git branch -r origin/HEAD -> origin/master origin/master origin/v0 $ git branch * master v0 

¿Por qué A y B tienen vistas diferentes del repository remoto?

git pull no elimina las twigs locales de seguimiento remoto, como origin/v0 , que están rastreando twigs remotas que ya no existen en el control remoto.

Si desea eliminar las sucursales obsoletas de seguimiento remoto de su repository local, debe usar

 git fetch <remote> --prune # Or shorter git fetch <remote> -p 

Documentación

Desde el espejo de Jan de los documentos oficiales de git fetch :

 -p --prune 

Después de recuperar, elimine todas las references de seguimiento remoto que ya no existan en el control remoto. Las tags no están sujetas a limitación si solo se obtienen debido al seguimiento automático de tags pnetworkingeterminado o debido a una opción --tags . Sin embargo, si las tags se obtienen debido a un refspec explícito (ya sea en la línea de command o en la configuration remota, por ejemplo, si el control remoto se clonó con la opción --mirror ), entonces también están sujetos a la eliminación.

Si desea una explicación aún más detallada acerca de los diferentes types de twigs en Git (local, remoto y de seguimiento remoto) y cómo eliminarlas, puede leer sobre todas ellas en mi respuesta a ¿Cómo elimino una twig de Git? tanto a nivel local como a distancia .

¿Por qué esperarías que fueran iguales? (Esto se entiende como una pregunta real, puedo pensar en algunas razones para esperarlo. Obviamente no son lo mismo, entonces esas razones deben estar equivocadas. Puede pensar en un set diferente de "posibles razones para esperar que lo hagan". ser el mismo "de lo que yo lo haría, sin embargo, por lo que es un ejercicio útil para que pienses por qué esperabas que fueran lo mismo.)


En cualquier caso, a git realmente no le importa mucho lo que hay en otro repository (en la misma computadora o en otra computadora). Funciona en un repository a la vez y solo se preocupa por lo que hay en ese repository.

También es importante tener en count que git pull es un script que hace dos cosas: primero, ejecuta git fetch , que es el command real que contacta a otro git (generalmente, pero no necesariamente , en otra computadora) para averiguar ". lo que tienen que no haces ". Luego, una vez hecho esto, git pull ejecuta git merge o git rebase 1 si es necesario.

El "otro git" se llama "el remoto", y para un clon típico, solo hay un origin remoto.

El command git push también habla con un (o el) "control remoto" -que de nuevo, por lo general, pero no necesariamente, en una computadora diferente- y solicita que el control remoto, que es otro repository git, actualice su (el remoto) sucursales locales

Ahora necesitamos un poco más de información de antecedentes. Su propio git intenta hacer un seguimiento de "lo que está en el control remoto" utilizando twigs de "seguimiento remoto". Estas son las twigs que se muestran como origin/ whatever . De nuevo, esto es independiente del lugar donde se encuentra el control remoto: estas copys de las tags de las sucursales remotas se almacenan localmente.


Cuando hiciste git push --delete v0 que tu git llamara al otro git y le git push --delete v0 (al otro git) que borrara su v0 . Lo hizo, borró la twig (local) v0 que tenía antes de esa date y tu git luego eliminó tu copy local, que tu git llamó a origin/v0 .

Cuando más tarde cambiaste a un clon diferente, ejecutaste git pull que ejecutaba git fetch . Esta git fetch llama al otro git (generalmente en otra computadora, pero en este caso, en la misma computadora portátil). Voy a pasar por alto algunos detalles aquí (detalles que dependen de la versión de Git en particular: hubo un cambio bastante importante en Git 1.8.4 más o less) y pretenden que ejecutaste git fetch (lo que evita tener que preocuparte por estos detalles, que en realidad no afectan el resultado final).

Esta vez, su git fetch llama al git remoto y le pregunta qué tiene ahora, y el control remoto no muestra v0 , ya que ahora se ha ido del control remoto. Esto le da a su git (local) un pequeño problema. Tu git local obtuvo v0 de ese git remoto hace un time, y ahora se ha ido. ¿Debería su git local eliminar su origin/v0 , o debería conservarlo?

La respuesta que los progtwigdores de git eligieron aquí es que su git debería mantener su origin/v0 , en caso de que lo estuviese usando para algo. Si quiere que su git fetch elimine su copy de origin/v0 local de la v0 que ahora falta en el control remoto, debe agregar la opción --prune a su command git fetch . 2 Esto le dice a su git local que elimine su origin/ whatever local origin/ whatever que origin/ whatever cuando el control remoto se haya apagado. De lo contrario, su git local lo conserva.

¿Por qué git push --delete delete it, cuando git fetch sin --prune mantiene? Esa es una pregunta para la gente que escribe git. 3


1 El valor pnetworkingeterminado es ejecutar git merge , si no configura nada para anular el valor pnetworkingeterminado. Dado que git rebase es probablemente un mejor pnetworkingeterminado, hay muchas maneras de hacer que pull uso.

2 También puede usar git remote prune origin o git remote update origin --prune . Hubo algunos pequeños errores de git que hicieron que cada uno actuara de forma ligeramente diferente. Por lo que yo sé, todos están arreglados en las versiones de Git 2.0 o superior.

3 Puedo adivinar , 4 por supuesto: parece que si usted, el usuario que ejecuta git push , está diciendo que desea eliminar una twig de un control remoto, probablemente no desea particularmente conservar su copy local de su twig una vez que he eliminado con éxito su twig. Pero es solo una suposition.

4 Puedo llamar a espíritus de lo vasto profundo también, pero nunca han aparecido. 🙂

Dependiendo de su configuration, git pull puede tirar solamente de la twig en la que se encuentra. Prueba git fetch, y luego git branch -r.