with pages page domain git git-branch github-pages

pages - ¿Por qué llamar git branch--unset-upstream para arreglar?



github pages with domain (6)

En realidad, te dije que ya sabes cómo usar las herramientas mucho mejor de lo que sería capaz de hacer. Sin embargo, en este caso, creo que es importante señalar algo peculiar si sigue las pautas en http://octopress.org/docs/deploying/github/ . A saber, tendrá múltiples repositorios Github en su configuración. En primer lugar, el que tiene todo el código fuente de su sitio web, por ejemplo, el directorio $WEBSITE , y luego el que solo $WEBSITE/_deploy archivos estáticos generados que residen en $WEBSITE/_deploy . Lo divertido de la configuración es que hay un archivo .gitignore en el directorio $WEBSITE para que esta configuración realmente funcione.

Suficiente presentación. En este caso, el error también podría provenir del repositorio en _deploy .

cd _deploy git branch -a * master remotes/origin/master remotes/origin/source

En .git/config normalmente necesitarás encontrar algo como esto:

[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = [email protected]:yourname/yourname.github.io.git fetch = +refs/heads/*:refs/remotes/origin/* [branch "master"] remote = origin merge = refs/heads/master

Pero en su caso, el maestro de sucursal no tiene un control remoto.

[core] repositoryformatversion = 0 filemode = true bare = false logallrefupdates = true [remote "origin"] url = [email protected]:yourname/yourname.github.io.git fetch = +refs/heads/*:refs/remotes/origin/*

Que puedes resolver por:

cd _deploy git branch --set-upstream-to=origin/master

Entonces, todo es como te lo dijo Torek, pero podría ser importante señalar que esto podría afectar al directorio _deploy lugar de a la raíz de tu sitio web.

PD: valdría la pena usar un shell como zsh con un plugin de git para no ser mordido por esto en el futuro. Inmediatamente mostrará que _deploy refiere a un repositorio diferente.

Soy más un novato cuando se trata de operaciones avanzadas en git. Octopress mi blog usando el marco de blog Octopress . Aunque Octopress no está en desarrollo desde 2011, cumple mi propósito bien, así que no he pensado en cambiar nada hasta ahora.

FYI, mi blog está alojado en Github Pages.

Hoy, mientras trabajaba en una nueva publicación, el git status mostró el siguiente mensaje:

On branch source Your branch is based on ''origin/master'', but the upstream is gone. (use "git branch --unset-upstream" to fixup)

El mismo mensaje se repite para todos los comandos posteriores, como git add . , git commit -m ''message'' y git push origin source .

  • ¿Qué significa el mensaje?
  • ¿Hay algo roto?
  • Si es así, ¿qué?
  • ¿Necesito arreglarlo?

Si es posible, diríjanme a un artículo pdf / web donde pueda leer sobre esto y entenderlo para el futuro.

Más detalles:

bash-3.2$ git branch -a * source remotes/octopress/2.1 remotes/octopress/HEAD -> octopress/master remotes/octopress/gh-pages remotes/octopress/linklog remotes/octopress/master remotes/octopress/refactor_with_tests remotes/octopress/rubygemcli remotes/octopress/site remotes/origin/source

Por favor, avíseme si se necesita más información. Gracias.

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

La respuesta de torek es probablemente perfecta, pero solo quería que el registro mencionara otro caso diferente al descrito en la pregunta original, pero podría aparecer el mismo error (ya que puede ayudar a otros con problemas similares):

He creado un repositorio vacío (nuevo) usando git init --bare en uno de mis servidores. Luego lo he git clone en un espacio de trabajo local en mi PC.

Después de confirmar una única versión en el repositorio local, recibí el error después de llamar al git status .

Siguiendo la respuesta de torek, entiendo que lo que sucedió es que la primera confirmación del repositorio de directorio de trabajo local creó una rama "maestra". Pero en el repositorio remoto (en el servidor) nunca había nada, por lo que no había ni siquiera una rama "maestra" (remotos / origen / maestro).

Después de ejecutar git push origin master del repositorio local, el repositorio remoto finalmente tenía una rama principal. Esto detuvo el error de aparecer.

Por lo tanto, para concluir, uno puede obtener ese error para un repositorio remoto nuevo y nuevo con cero confirmaciones, ya que no tiene ninguna rama, incluido "maestro".

Para mí, .git/refs/origin/master había corrompido.

Hice lo siguiente, que me solucionó el problema.

rm .git/refs/remotes/origin/master git fetch git branch --set-upstream-to=origin/master

TL; Versión DR: el origin/master remoto de la sucursal solía existir, pero ahora no, por lo que la source sucursal local está rastreando algo que no existe, que es sospechoso en el mejor de los casos; significa que una función diferente no puede hacer nada por usted Y Git te lo advierte. Se ha estado llevando bien sin que la función de "seguimiento en sentido ascendente" funcione según lo previsto, por lo que depende de usted cambiar cualquier cosa.

Esta advertencia es algo nuevo en git, que aparece primero en git 1.8.5. Las notas de la versión contienen solo un breve punto sobre el tema:

  • "git branch -v -v" (y "estado de git") no distinguía entre una rama que no está basada en ninguna otra rama, una rama que está sincronizada con su rama ascendente, y una rama que está configurada con una corriente ascendente rama que ya no existe

Para describir lo que significa, primero necesita saber acerca de "controles remotos", "ramas remotas" y cómo maneja git el "seguimiento de un flujo ascendente".

Cada "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 cuales git fetch o git pull updates. 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 registra las actualizaciones, usando "ramas remotas".

Una "rama remota" es simplemente una grabación de una rama como la última vez que se vio en algún "remoto". Cada control remoto es en sí mismo un repositorio git, por lo que tiene ramas. Las ramas en el "origen" remoto se registran en su repositorio local bajo remotes/origin/ . El texto que mostró dice que hay una rama llamada source on origin , y branches named 2.1 , linklog , etc. en octopress .

(Una rama "normal" o "local", por supuesto, es solo un nombre de sucursal que ha creado en su propio repositorio).

Por último, puede configurar una rama (local) para "rastrear" una "rama remota". Una vez que la rama local L está configurada para rastrear la rama remota R , git llamará a R "ascendente" y le dirá si está "adelantado" y / o "detrás" de la corriente ascendente (en términos de confirmaciones). Es normal (incluso recomendable) que la sucursal local y las sucursales remotas usen el mismo nombre (excepto la parte del prefijo remoto), como source y origin/source , pero eso no es realmente necesario.

Y en este caso, eso no está sucediendo. Usted tiene una source sucursal local source rastrea un origin/master una sucursal remota.

Se supone que no necesitas saber la mecánica exacta de cómo git configura una sucursal local para rastrear una remota, pero son relevantes a continuación, así que te mostraré cómo funciona esto. Comenzamos con su nombre de sucursal local, source . Hay dos entradas de configuración que usan este nombre, deletreado branch.source.remote y branch.source.merge . A partir de la salida que mostró, está claro que ambos están configurados, de modo que vería lo siguiente si ejecutó los comandos dados:

$ git config --get branch.source.remote origin $ git config --get branch.source.merge refs/heads/master

Al unir esto, 2 esto le dice a git que su source sucursal rastrea su "sucursal remota", origin/master .

Pero ahora mira la salida de git branch -a , que muestra todas las ramas locales y remotas en tu repositorio. Las ramas remotas se enumeran en remotes/ ... y no hay remotes/origin/master . Presumiblemente había, al mismo tiempo, pero ahora se ha ido.

Git te dice que puedes eliminar la información de seguimiento con --unset-upstream . Esto eliminará tanto branch.source.origin como branch.source.merge y detendrá la advertencia.

Parece bastante probable que lo que desee, sin embargo, sea pasar del seguimiento del origin/master al seguimiento de otra cosa: probablemente origin/source , pero tal vez uno de los nombres octopress/ .

Puede hacer esto con la git branch --set-upstream-to , 3 por ejemplo:

$ git branch --set-upstream-to=origin/source

(suponiendo que todavía está en la "fuente" de la sucursal, y que el origin/source es la corriente ascendente que desea, no hay manera de que yo diga cuál, en su caso, realmente quiere).

(Consulte también ¿Cómo hacer que una rama de Git existente rastree una rama remota? )

Creo que la forma en que llegaste aquí es que la primera vez que hiciste un git clone , lo que clonaste tenía un master rama. También tenía un master rama, que estaba configurado para rastrear origin/master (esta es una configuración normal y estándar para git). Esto significaba que tenía branch.master.remote y branch.master.merge set, a origin y refs/heads/master . Pero luego su control remoto de origin cambió su nombre de master a source . Para que coincida, creo que también cambiaste tu nombre local de master a source . Esto cambió los nombres de su configuración, de branch.master.remote a branch.source.remote y de branch.master.merge a branch.source.merge ... pero dejó los valores anteriores , por lo que branch.source.merge era ahora está mal

Fue en este punto cuando se rompió el enlace "aguas arriba", pero en las versiones git anteriores a 1.8.5, git nunca notó la configuración errónea. Ahora que tiene 1.8.5, lo señala.

Eso cubre la mayoría de las preguntas, pero no la respuesta "¿Necesito arreglarlo?" Es probable que hayas estado trabajando en torno a la ruptura desde hace años, haciendo git pull remote branch (por ejemplo, git pull origin source ). Si continúa haciendo eso, seguirá trabajando en torno al problema, por lo tanto, no, no necesita repararlo. Si lo desea, puede usar --unset-upstream para eliminar el --unset-upstream ascendente y detener las reclamaciones, y no tener marca de source local marcada como ascendente en absoluto.

El objetivo de tener un upstream es hacer varias operaciones más convenientes. Por ejemplo, git fetch seguido de git merge generalmente "hará lo correcto" si el upstream está configurado correctamente, y el git status git fetch después de git fetch le dirá si su repo coincide con el upstream, para esa rama.

Si desea la conveniencia, vuelva a configurar el flujo ascendente.

1 git pull usa git fetch , y desde git 1.8.4, esto (¡finalmente!) También actualiza la información de "remote branch". En versiones anteriores de git, las actualizaciones no se registraban en sucursales remotas con git pull , solo con git fetch . Como su git debe ser al menos la versión 1.8.5, este no es un problema para usted.

2 Bueno, esto más una línea de configuración que ignoro deliberadamente que se encuentra en remote.origin.fetch . Git tiene que mapear el nombre de "fusión" para descubrir que el nombre local completo de la rama remota es refs/remotes/origin/master . Sin embargo, el mapeo casi siempre funciona así, por lo que es predecible que el master vaya al origin/master .

3 O bien, con git config . Si solo desea configurar el branch.source.merge ascendente a 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 lo que quiere que se haga, en lugar de --set-upstream-to hacerlo manualmente, así que esa es una "mejor manera".

Tuve esta pregunta dos veces, y siempre fue causada por la corrupción del archivo git cache en mi sucursal local. Lo arreglé escribiendo el hash de confirmación faltante en ese archivo. Obtuve el hash correcto de commit del servidor y ejecuté el siguiente comando localmente:

cat .git/refs/remotes/origin/feature/mybranch / echo 1edf9668426de67ab764af138a98342787dc87fe / >> .git/refs/remotes/origin/feature/mybranch