El post "Upstream gone" al volver a una twig principal vacía?

Mi versión de git es Git-1.9.4-preview20140611 Anteriormente, cloné un repository de origen de git vacío. El repository clonado pero con el siguiente post

advertencia: Parece que ha clonado un repository vacío. Comprobando la conectividad … hecho.

A continuación, copió un file .gitIgnore que estaba en el repository maestro de Git de otro proyecto y lo asignó al maestro local. Este file ha sido utilizado por nosotros muchas veces antes. Esto parece estar bien. Tenemos un file .gitIgnore estandarizado para todos nuestros proyectos. Esto fue creado como parte de las mejores prácticas.

Luego creó una nueva sucursal y copió un código en la location física donde reside el git repo local.

git checkout -b FromCC 

Se agregó el código y se cometió en esta twig.

 git add --all git commit -M "Blah" 

Todas estas operaciones son exitosas.

Mi propósito es fusionar estos cambios eventualmente en la twig maestra local.

A continuación, hago

 git checkout master 

y recibe el siguiente post.

Su sucursal se basa en 'origin / master', pero el upstream se ha ido. (use "git branch –unset-upstream" para arreglar)

¿Qué significa este post? ¿Por qué la stream ascendente 'se iría'?

Observación interesante: repetí el mismo process con el mismo repository principal de Git hoy. Esta vez el repository de Git no estaba vacío. Tenía un file .gitIgnore antes de la mano. Esta vez el post antes mencionado no apareció.

No es el repository en sentido ascendente ( origin sí) sino la twig específica que clonó ( master en el origen) que falta.

Además, el post de git es engañoso: el master twig en el origen no desapareció , nunca estuvo allí . Cuando clonaste el repository vacío, no tenía twigs. Continuó sin twigs. Por lo tanto, su master local, que se estableció para rastrear el origin/master , estaba (es) rastreando una twig que no existió (no existe).

El post es más para una situación como esta:

 $ git clone ... $ git checkout featureX # track some feature branch [go away for a week, come back] $ git fetch -p # update remote branches 

donde, durante esa semana en que estuvo ausente, la twig featureX fue eliminada (presumiblemente fusionada en su línea de desarrollo y luego ya no es necesaria). En este punto se encuentra en una sucursal local, featureX , configurada para rastrear origin/featureX , pero ya no hay origin/featureX .

En este caso, sin embargo, tiene origin/master seguimiento de master bifurcación local cuando todavía no hay origin/master . Una vez que lo haya creado (mediante la inserción que hace que el repository no esté vacío), el problema desaparecerá. Esto surgió solo porque de manera pnetworkingeterminada, usted comienza con el master incluso si el control remoto está vacío y todavía no tiene un master .

Como novato en git / github me encontré con esto después de crear un repository completamente vacío en github y git clone d en local. Incluyendo la advertencia sobre un repository vacío. A continuación, un compromiso para un file local creado recientemente dio el post con respecto a "aguas arriba se ha ido".

Lo siguiente asume que uno quiere usar el repository remoto, por lo tanto, el upstream sería necesario para establecer:

Pensé agregar, que Github sugirió al crear el repository vacío algunos commands. El más crítico sería el git push -u origin master (después de init , add (para un file), commit y remote add origin <url> ). Esto transfiere el maestro localmente existente al repository remoto de github.

El -u cambiar a push establece el upstream (la versión larga es –set-upstream) al set en github. Tengo que admitir que el rest de la página de manual de git-push para ese conmutador sigue siendo místico para mí … ya que el local no está actualizado ni es exitoso.

El post se ha ido porque la twig maestra ahora también está disponible en el repository remoto.

Tuve el mismo post de error con github. El problema real era que no había aprobado la invitación al repository. Entonces el idiota pensó que no tenía los derechos para el repository.