¿Por qué tengo que "git push --set-upstream origin <branch>"?

Creé una sucursal local para probar Solaris y Sun Studio. Luego empujé la rama río arriba. Después de cometer un cambio e intentar impulsar los cambios:

$ git commit blake2.cpp -m "Add workaround for missing _mm_set_epi64x"
[solaris 7ad22ff] Add workaround for missing _mm_set_epi64x
 1 file changed, 5 insertions(+)
$ git push
fatal: The current branch solaris has no upstream branch.
To push the current branch and set the remote as upstream, use

    git push --set-upstream origin solaris

¿Por qué tengo que hacer algo especial para esto?

¿Hay algún caso de uso razonable en el que alguien cree <branch>, presione el <branch>control remoto y luego afirme que <branch>no se supone que sea un compromiso <branch>?

Seguí esta pregunta y respuesta en Stack Overflow: empuje una nueva sucursal local a un repositorio Git remoto y realice un seguimiento también . Supongo que es otra instancia de una respuesta aceptada incompleta o incorrecta. O bien, es otra instancia de Git que toma una tarea simple y la dificulta.

Aquí está la vista en una máquina diferente. La rama claramente existe, por lo que fue creada y empujada:

$ git branch -a
  alignas
* master
  remotes/origin/HEAD -> origin/master
  remotes/origin/alignas
  remotes/origin/arm-neon
  remotes/origin/det-sig
  remotes/origin/master
  remotes/origin/solaris

TL; DR: git branch --set-upstream-to origin/solaris

La respuesta a la pregunta que hizo, que reformularé un poco como "¿Tengo que configurar un flujo ascendente?" Es: no, no tiene que configurar un flujo ascendente en absoluto.

Sin embargo, si no tiene un flujo ascendente para la rama actual, Git cambia su comportamiento git pushy otros comandos también.

La historia de empuje completa aquí es larga y aburrida y se remonta a la historia anterior a Git versión 1.5. Para acortarlo mucho, git pushse implementó mal. ¹ A partir de Git versión 2.0, Git ahora tiene una perilla de configuración deletreada push.defaultque ahora está predeterminada simple. Durante varias versiones de Git antes y después de 2.0, cada vez que se ejecutó git push, Git podría arrojar un montón de ruido tratando de convencer a establecer push.defaultsólo para conseguir git pushque se calle.

No menciona qué versión de Git está ejecutando, ni si ha configurado push.default, por lo que debemos adivinar. Supongo que está utilizando Git versión 2-point-something, y que ha configurado push.defaultpara simpleque se calle. Precisamente la versión de Git que tiene, y lo que si hay algo que ha push.defaultajustado en, lo hace la materia, debido a que la historia larga y aburrida, pero al final, el hecho de que usted está recibiendo otra queja de Git indica que su Git es configurado para evitar uno de los errores del pasado.

¿Qué es un upstream?

Un flujo ascendente es simplemente otro nombre de rama, generalmente una rama de seguimiento remoto, asociada con una rama (regular, local).

Cada rama tiene la opción de tener un (1) conjunto ascendente. Es decir, cada rama tiene un flujo ascendente o no tiene un flujo ascendente. Ninguna sucursal puede tener más de una corriente arriba.

El flujo ascendente debería , pero no tiene que ser, una rama válida (ya sea de seguimiento remoto o local ). Es decir, si la rama actual B tiene U ascendente , debería funcionar. Si no funciona, si se queja de que U no existe, la mayoría de Git actúa como si el flujo ascendente no estuviera configurado. Algunos comandos, como , mostrarán la configuración aguas arriba pero la marcarán como "desaparecida".origin/Bmastergit rev-parse U git branch -vv

¿De qué sirve una corriente arriba?

Si push.defaultse establece en simpleo upstream, la configuración ascendente hará que git push, utilizada sin argumentos adicionales, simplemente funcione.

Eso es todo, eso es todo lo que hace git push. Pero eso es bastante significativo, ya que git pushes uno de los lugares donde un error tipográfico simple causa grandes dolores de cabeza.

Si su push.defaultestá configurado en nothing, matchingo current, establecer un flujo ascendente no sirve para nada git push.

(Todo esto supone que su versión de Git es al menos 2.0).

La corriente arriba afecta git fetch

Si ejecuta git fetchsin argumentos adicionales, Git descubre qué control remoto debe buscar consultando el flujo ascendente de la rama actual. Si el flujo ascendente es una rama de seguimiento remoto, Git obtiene de ese control remoto. (Si el flujo ascendente no está configurado o es una rama local, Git intenta buscarlo origin).

La corriente arriba afecta git mergey git rebasetambién

Si ejecuta git mergeo git rebaseno tiene argumentos adicionales, Git usa el flujo ascendente de la rama actual. Por lo tanto, acorta el uso de estos dos comandos.

La corriente arriba afecta git pull

Nunca se debe ² uso git pullde todos modos, pero si lo hace, git pullutiliza la configuración de aguas arriba para averiguar qué distancia para buscar a partir, y luego que se ramifican a fusionarse o rebase con. Es decir, git pullhace lo mismo que, git fetchporque realmente se ejecuta, git fetch y luego hace lo mismo que git mergeo git rebase, porque realmente se ejecuta git merge o git rebase.

(Por lo general, solo debe hacer estos dos pasos manualmente, al menos hasta que conozca a Git lo suficientemente bien como para que cuando cualquiera de los pasos falle, lo que eventualmente ocurrirá, reconozca lo que salió mal y sepa qué hacer al respecto).

La corriente arriba afecta git status

Esto en realidad puede ser lo más importante. Una vez que tenga un conjunto ascendente, git statuspuede informar la diferencia entre su rama actual y su ascendente, en términos de confirmaciones.

Si, como es el caso normal, usted está en una rama Bcon su flujo ascendente establecido y ejecuta , inmediatamente verá si tiene compromisos que puede impulsar y / o compromisos en los que puede fusionar o rebasar.origin/Bgit status

Esto se debe a que se git statusejecuta:

• git rev-list --count @{u}..HEAD: ¿cuántos commits tienes Bque no están en ?origin/B
• git rev-list --count HEAD..@{u}: ¿cuántos commits tienes que no están en ?origin/BB

Establecer un flujo ascendente le brinda todas estas cosas.

¿Cómo es que masterya tiene un conjunto aguas arriba?

Cuando clones por primera vez desde un control remoto, usa:

$ git clone git://some.host/path/to/repo.git

o similares, el último paso Git hace es, esencialmente, git checkout master. Esto verifica tu sucursal local, solo masterque no tienes una sucursal local master.

Por otra parte, usted no tiene una rama remota de seguimiento de nombre origin/master, ya que acaba de clonado él.

Git adivina que debe haber significado: "me hace un nuevo local, masterque apunta a la misma se comprometen a distancia como de seguimiento origin/master, y, mientras estás en ello, ajuste la corriente arriba para masterque origin/master."

Esto sucede para cada rama git checkoutque aún no tienes. Git crea la rama y la hace "rastrear" (tener como un flujo ascendente) la rama de seguimiento remoto correspondiente.

Pero esto no funciona para nuevas sucursales, es decir, sucursales sin sucursal de seguimiento remoto todavía .

Si crea una nueva rama:

$ git checkout -b solaris

hay, hasta ahora, no origin/solaris. Su local solaris no puede rastrear la rama de seguimiento remoto origin/solarisporque no existe.

Cuando empuja la nueva rama por primera vez:

$ git push origin solaris

eso crea solaris en origin, y por lo tanto también crea origin/solarisen su propio repositorio de Git. Pero es demasiado tarde: ya tienes un local solarisque no tiene corriente arriba . ³

¿No debería Git configurar eso, ahora, como el flujo ascendente automáticamente?

Probablemente. Ver "implementado mal" y la nota al pie 1. Es difícil cambiar ahora : hay millones ⁴ de scripts que usan Git y algunos bien pueden depender de su comportamiento actual. Cambiar el comportamiento requiere una nueva versión principal, un programa para forzarlo a establecer algún campo de configuración, etc. En resumen, Git es víctima de su propio éxito: cualquier error que tenga, hoy en día, solo puede repararse si el cambio es mayormente invisible, claramente mucho mejor o se hace lentamente con el tiempo.

El hecho es que no lo hace hoy, a menos que use --set-upstreamo -udurante el git push. Eso es lo que te dice el mensaje.

No tienes que hacerlo así. Bueno, como señalamos anteriormente, no tiene que hacerlo en absoluto, pero supongamos que desea un flujo ascendente. Ya ha creado una sucursal solarisen origin, a través de una inserción anterior, y como git branchmuestra su salida, ya tiene origin/solaris en su repositorio local.

Simplemente no lo tiene configurado como upstream solaris.

Para configurarlo ahora, en lugar de durante el primer impulso, use git branch --set-upstream-to. El --set-upstream-tosubcomando toma el nombre de cualquier rama existente, como origin/solaris, y establece la rama actual en sentido ascendente a esa otra rama.

Eso es todo, eso es todo lo que hace, pero tiene todas las implicaciones mencionadas anteriormente. Significa que puede simplemente correr git fetch, luego mirar a su alrededor, luego correr git mergeo, git rebasesegún corresponda, hacer nuevos commits y ejecutar git push, sin un montón de problemas adicionales.

¹ Para ser justos, en ese momento no estaba claro que la implementación inicial fuera propensa a errores. Eso solo quedó claro cuando cada nuevo usuario cometió los mismos errores cada vez. Ahora es "menos pobre", lo que no quiere decir "genial".

² "Nunca" es un poco fuerte, pero encuentro que los novatos de Git entienden mucho mejor las cosas cuando separo los pasos, especialmente cuando puedo mostrarles lo que git fetchrealmente hizo, y luego pueden ver qué git mergeo qué git rebaseharán a continuación.

³ Si ejecuta su primer git push como git push -u origin solaris—es decir, si agrega la -ubandera— Git se establecerá origin/solariscomo el flujo ascendente para su rama actual si (y solo si) el empuje tiene éxito. Por lo tanto, debe suministrar -uen el primer empujón. De hecho, puede suministrarlo en cualquier inserción posterior, y establecerá o cambiará el flujo ascendente en ese punto. Pero creo que git branch --set-upstream-toes más fácil, si lo olvidaste.

⁴ Medido por el método Austin Powers / Dr Evil de decir simplemente "un MILLLL-YUN", de todos modos.

La diferencia entre
git push origin <branch>
y
git push --set-upstream origin <branch>
es que ambos empujan muy bien al repositorio remoto, pero es cuando tiras que notas la diferencia.

Si lo haces:
git push origin <branch>
al tirar, tienes que hacer:
git pull origin <branch>

Pero si lo haces:
git push --set-upstream origin <branch>
entonces, al tirar, solo tienes que hacer:
git pull

Por lo tanto, agregarlo --set-upstreampermite no tener que especificar de qué rama desea extraer cada vez que lo hace git pull.

Un comando básicamente completo es como git push <remote> <local_ref>:<remote_ref>. Si ejecuta solo git push, git no sabe qué hacer exactamente a menos que haya realizado alguna configuración que ayude a git a tomar una decisión. En un repositorio de git, podemos configurar múltiples controles remotos. También podemos enviar una referencia local a cualquier referencia remota. El comando completo es la forma más directa de dar un empujón. Si desea escribir menos palabras, primero debe configurar, como --set-upstream.