Tenga en cuenta primero que su pregunta muestra un poco de malentendido. origin / HEAD representa la rama predeterminada en el control remoto , es decir, el HEAD que está en ese repositorio remoto al que está llamando origen. Cuando cambias ramas en tu repositorio, no estás afectando eso. Lo mismo es cierto para las ramas remotas; es posible que tenga mastery origin/masteren su repositorio, donde origin/masterrepresenta una copia local de la masterrama en el repositorio remoto.
HEAD de origen solo cambiará si usted u otra persona realmente lo cambia en el repositorio remoto , lo que básicamente nunca debería suceder: desea que la rama predeterminada un repositorio público permanezca constante, en la rama estable (probablemente maestra). origin / HEAD es una referencia local que representa una copia local de HEAD en el repositorio remoto. (Su nombre completo es refs / remotes / origin / HEAD).
Creo que lo anterior responde a lo que realmente quería saber, pero para seguir adelante y responder la pregunta que hizo explícitamente ... origin / HEAD se configura automáticamente cuando clona un repositorio, y eso es todo. Curiosamente, que está no mediante comandos como git remote update- Creo que la única forma en que va a cambiar es si cambia manualmente. (Por cambio me refiero a apuntar a una rama diferente; obviamente, la confirmación apunta a cambios si esa rama cambia, lo que podría suceder en la búsqueda / extracción / actualización remota).
Editar : El problema discutido a continuación se corrigió en Git 1.8.4.3 ; ver esta actualización .
Sin embargo, hay una pequeña advertencia. HEAD es una referencia simbólica, que apunta a una rama en lugar de directamente a una confirmación, pero los protocolos de transferencia remota de git solo informan confirmaciones para las referencias. Entonces Git conoce el SHA1 del commit señalado por HEAD y todas las demás referencias; luego tiene que deducir el valor de HEAD encontrando una rama que apunte al mismo commit. Esto significa que si dos ramas apuntan allí, es ambiguo. (Creo que elige maestro si es posible, luego vuelve a alfabéticamente primero). Verá esto informado en la salida de git remote show origin:
$ git remote show origin
* remote origin
Fetch URL: ...
Push URL: ...
HEAD branch (remote HEAD is ambiguous, may be one of the following):
foo
master
Curiosamente, aunque la noción de HEAD impresa de esta manera cambiará si las cosas cambian en el control remoto (por ejemplo, si se elimina foo), en realidad no se actualiza refs/remotes/origin/HEAD. Esto puede conducir a situaciones realmente extrañas. Digamos que en el ejemplo anterior origin / HEAD en realidad apuntaba a foo, y luego se quitó la rama foo de origen. Entonces podemos hacer esto:
$ git remote show origin
...
HEAD branch: master
$ git symbolic-ref refs/remotes/origin/HEAD
refs/remotes/origin/foo
$ git remote update --prune origin
Fetching origin
x [deleted] (none) -> origin/foo
(refs/remotes/origin/HEAD has become dangling)
Entonces, aunque el programa remoto sabe que HEAD es maestro, no actualiza nada. La rama viciada se poda correctamente, y HEAD se cuelga (apuntando a una rama inexistente), y aún no se actualiza para señalar al maestro. Si desea arreglar esto, use git remote set-head origin -a, que determina automáticamente el HEAD del origen como se indica arriba, y luego establece el origen / HEAD para que apunte a la rama remota apropiada.
refs/origin/HEAD. No se trata de cómoHEADse establece la referencia simbólica de un repositorio .