Solución:
TL; Versión DR: rama de seguimiento remoto origin/master solía existir, pero ahora no, así que la sucursal local source está rastreando algo que no existe, lo cual es sospechoso en el mejor de los casos (significa que una función de Git diferente no puede hacer nada por usted) y Git le advierte al respecto. Se ha estado llevando bien sin que la función de “seguimiento ascendente” funcione según lo previsto, por lo que depende de usted si desea cambiar algo.
Para ver otra versión de la configuración ascendente, consulte ¿Por qué tengo que “git push –set-upstream origin
Esta advertencia es algo nuevo en Git, que aparece primero en Git 1.8.5. Las notas de la versión contienen solo una pequeña viñeta al respecto:
- “git branch -v -v” (y “git status”) no distinguían entre una rama que no se basa en ninguna otra rama, una rama que está sincronizada con su rama ascendente y una rama que está configurada con una rama ascendente rama que ya no existe.
Para describir lo que significa, primero necesita saber sobre “controles remotos”, “ramas de seguimiento remoto” y cómo Git maneja el “seguimiento de un flujo ascendente”. (Sucursales de seguimiento remoto es un término terriblemente defectuoso; empecé a usar nombres de seguimiento remoto en cambio, lo que creo que es una ligera mejora. Sin embargo, a continuación, usaré “rama de seguimiento remoto” para mantener la coherencia con la documentación de Git).
Cada “control remoto” es simplemente un nombre, como origin o octopress en este caso. Su propósito es registrar cosas como la URL completa de los lugares desde los que git fetch o git pull actualizaciones. Cuando usas git fetch remote,1 Git va a ese control remoto (usando la URL guardada) y trae el conjunto apropiado de actualizaciones. También registros las actualizaciones, utilizando “ramas de seguimiento remoto”.
Una “rama de seguimiento remoto” (o nombre de seguimiento remoto) es simplemente una grabación del nombre de una rama como se vio por última vez en algún “remoto”. Cada control remoto es en sí mismo un repositorio de Git, por lo que tiene ramas. Las ramas en “origen” remoto se registran en su repositorio local en remotes/origin/. El texto que mostró dice que hay una rama llamada source sobre originy ramas denominadas 2.1, linklogy así sucesivamente octopress.
(Una rama “normal” o “local”, por supuesto, es solo un nombre de rama que ha creado en su propio repositorio).
Por último, puede configurar una rama (local) para “rastrear” una “rama de rastreo remoto”. Una vez sucursal local L está configurado para rastrear la rama de seguimiento remoto R, Git llamará R su “corriente arriba” y le dice si está “adelante” y / o “detrás” de la corriente arriba (en términos de confirmaciones). Es normal (incluso recomendable) que la sucursal local y las sucursales de seguimiento remoto usen el mismo nombre (excepto para la parte del prefijo remoto), como source y origin/source, pero eso no es realmente necesario.
Y en este caso, eso no está sucediendo. Tienes una sucursal local source seguimiento de una sucursal de seguimiento remoto origin/master.
Se supone que no necesitas conocer la mecánica exacta de cómo Git configura una sucursal local para rastrear una remota, pero son relevantes a continuación, así que mostraré cómo funciona esto. Comenzamos con el nombre de su sucursal local, source. Hay dos entradas de configuración que usan este nombre, escrito branch.source.remote y branch.source.merge. A partir de la salida que mostró, está claro que ambos están configurados, por lo que verá lo siguiente si ejecuta los comandos dados:
$ git config --get branch.source.remote
origin
$ git config --get branch.source.merge
refs/heads/master
Poniendo estos juntos,2 esto le dice a Git que tu rama source realiza un seguimiento de su “rama de seguimiento remoto”, origin/master.
Pero ahora mira la salida de git branch -a, que muestra todos los nombres de las ramas de seguimiento local y remoto en su repositorio. Los nombres de seguimiento remoto se enumeran en remotes/ … y no hay remotes/origin/master. Es de suponer que lo hubo, en un momento, pero ahora se ha ido.
Git te está diciendo que puedes retirar la información de seguimiento con --unset-upstream. Esto limpiará tanto branch.source.origin y branch.source.mergey detenga la advertencia.
Sin embargo, parece bastante probable que lo que desee sea cambiar de seguimiento origin/master, para rastrear algo más: probablemente origin/source, pero tal vez uno de los octopress/ nombres.
Puedes hacer esto con git branch --set-upstream-to,3 p.ej:
$ git branch --set-upstream-to=origin/source
(asumiendo que todavía estás en la rama “fuente”, y que origin/source es el contracorriente que desea; sin embargo, no tengo forma de decir cuál, si es que desea alguno, realmente desea).
(Consulte también ¿Cómo se puede hacer que una sucursal de Git existente realice un seguimiento de una sucursal remota?)
Creo que la forma en que llegaste aquí es que cuando hiciste por primera vez git clone, la cosa de la que clonaste tenía una rama master. Tu tambien tenias una rama master, que se configuró para rastrear origin/master (esta es una configuración estándar normal para git). Esto significaba que tenías branch.master.remote y branch.master.merge ajustado a origin y refs/heads/master. Pero entonces tu origin remoto cambió su nombre de master para source. Para que coincida, creo que también cambió su nombre local de master para source. Esto cambió el nombres de su configuración, desde branch.master.remote para branch.source.remote y de branch.master.merge para branch.source.merge … pero dejó lo viejo valores, asi que branch.source.merge ahora estaba mal.
Fue en este punto que se rompió el enlace “ascendente”, pero en las versiones de Git anteriores a la 1.8.5, Git nunca notó la configuración rota. Ahora que tiene 1.8.5, está señalando esto.
Eso cubre la mayoría de las preguntas, pero no la de “necesito solucionarlo”. Es probable que haya estado trabajando en torno al quebrantamiento durante años, haciendo git pull remote branch (p.ej, git pull origin source). Si sigue haciendo eso, seguirá solucionando el problema, así que no, no necesitar arreglarlo. Si lo desea, puede usar --unset-upstream para eliminar el upstream y detener las quejas, y no tener sucursal local source marcado como teniendo alguna aguas arriba en absoluto.
El objetivo de tener un flujo ascendente es hacer que varias operaciones sean más convenientes. Por ejemplo, git fetch seguido por git merge generalmente “hará lo correcto” si el upstream está configurado correctamente, y git status después git fetch le dirá si su repositorio coincide con el anterior, para esa rama.
Si desea la comodidad, vuelva a configurar el flujo ascendente.
1git pull usos git fetch, y a partir de Git 1.8.4, esto (¡finalmente!) también actualiza la información de la “rama de seguimiento remoto”. En versiones anteriores de Git, las actualizaciones no se registraban en las ramas de seguimiento remoto con git pull, solo con git fetch. Dado que su Git debe tener al menos la versión 1.8.5, esto no es un problema para usted.
2Bueno, esto más una línea de configuración que ignoro deliberadamente y que se encuentra debajo remote.origin.fetch. Git tiene que mapear el nombre de “fusión” para descubrir que el nombre local completo para la rama remota es refs/remotes/origin/master. Sin embargo, el mapeo casi siempre funciona así, por lo que es predecible que master va a origin/master.
3O con git config. Si solo desea configurar el upstream para origin/source la única parte que tiene que cambiar es branch.source.merge, y git config branch.source.merge refs/heads/source
Lo haría. Pero --set-upstream-to dice qué desea que se haga, en lugar de hacer que lo haga usted mismo manualmente, así que esa es una “mejor manera”.
La respuesta de torek es probablemente perfecta, pero solo quería que el registro mencionara otro caso que es diferente al descrito en la pregunta original, pero puede aparecer el mismo error (ya que puede ayudar a otros con un problema similar):
He creado un repositorio vacío (nuevo) usando git init --bare en uno de mis servidores. Luego tengo git clonedlo a un espacio de trabajo local en mi PC.
Después de confirmar una sola versión en el repositorio local, obtuve ese error después de llamar git status.
Siguiendo la respuesta de torek, entiendo que lo que sucedió es que la primera confirmación en el repositorio del directorio de trabajo local creó una rama “maestra”. Pero en el repositorio remoto (en el servidor) nunca hubo nada, por lo que ni siquiera había una rama “maestra” (remotes / origin / master).
despues de correr git push origin master desde el repositorio local, el repositorio remoto finalmente tenía una rama maestra. Esto impidió que apareciera el error.
Entonces, para concluir, uno puede obtener un error de este tipo para un nuevo repositorio remoto nuevo con cero confirmaciones, ya que no tiene rama, incluido “maestro”.
Esto podría resolver su problema.
después de hacer cambios, puede confirmarlo y luego
git remote add origin https://(address of your repo) it can be https or ssh
then
git push -u origin master
Espero que funcione para ti.
Gracias