2011-05-11 26 views
44

No entiendo la diferencia entre git rebase origin y git rebase origin/master. En mi caso, cloné un repositorio git dos veces. En el primer clon tengo que usar git rebase origin y en el otro clon debo usar git rebase origin/master."git rebase origin" vs. "git rebase origin/master"

Un ejemplo: http://paste.dennis-boldt.de/2011/05/11/git-rebase

+0

¿Podría dar más información sobre lo que está haciendo? 'origen de git rebase' no debería funcionar porque 'origen' es un control remoto, no una bifurcación (al menos de manera predeterminada, podría nombrar un origen de bifurcación). – asm

+0

Agregué un ejemplo a mi pregunta.Una vez que puedo usar 'git rebase origin' (línea 27). En el otro clon no funciona (línea 54), así que tengo que usar 'git rebase origin/master' (línea 57) – Dennis

+0

Ambos formularios usan [gitrevisions] (https://www.kernel.org/pub/ sintaxis de software/scm/git/docs/gitrevisions.html) para nombrar una confirmación específica. Como señala la página man, 'origin' significa", en efecto, "cualquiera de las ramas' origin/* 'se llama por' origin/HEAD' ". Más comúnmente, los nombres 'origin/HEAD'' origin/master' (esto aparece en la salida 'git branch -r', como' origin/HEAD -> origin/master'). Si 'origin/HEAD' es * missing *, acaba de obtener un error (como @Dennis lo hizo). Si '' git remote set-head' it (como en la respuesta aceptada) puede elegir cómo se resuelve 'origin/HEAD'. – torek

Respuesta

19

Aquí hay una mejor opción:

git remote set-head -a origin 

De la documentación:

Con -a, se consulta el control remoto para determinar su HEAD, luego $ GIT_DIR/controles remotos // HEAD se establece en la misma bifurcación. por ejemplo, si el HEAD remoto se señala a continuación, "git remote set-head origen -a" establecerá $ GIT_DIR/refs/remotes/origin/HEAD en refs/remotes/origin/next. Esto solo funcionará si refs/remotes/origin/next ya existe; si no, se debe buscar primero.

Esto ha sido desde hace bastante tiempo (desde v1.6.3); no estoy seguro de cómo me lo perdí!

+3

Nunca contesté: ¡Estoy usando mucho ahora, y está funcionando bien! – Dennis

+0

Cuando estaba intentando 'origen de git rebase', estaba viendo el error' origen ascendente no válido'. Ejecutar este comando solucionó mi problema. – DrStrangepork

48

git rebase origin significa "rebase de la rama de seguimiento de origin", mientras que git rebase origin/master significa "rebase de la rama master de origin"

Debe tener una rama de seguimiento en ~/Desktop/test, que significa que git rebase origin sabe con qué rama de origin reubicarse. Si no existe una rama de seguimiento (en el caso de ~/Desktop/fallstudie), git no sabe qué rama de origin debe tomar y falla.

Para solucionar este problema, se puede hacer la pista master rama existente origin/master con

git branch --set-upstream master origin/master 
+0

En realidad, encontré la única diferencia: 'test' está teniendo' remotes/origin/HEAD', además. Entonces, estás en lo correcto. ¿Cómo puedo agregar esto al clon 'fallstudie'? http://paste.dennis-boldt.de/2011/05/11/git-branch – Dennis

+0

'git branch --set-upstream master master/master' – CharlesB

+0

No es la solución. El error sigue siendo 'origen ascendente no válido' y todavía hay una sola rama de origen. – Dennis

2

Puede hacer un nuevo archivo en [.git \ árbitros \ remotos \ origen] con el nombre de "cabeza" y poner el contenido "ref: refs/remotes/origin/master" a él. Esto debería solucionar tu problema.

Parece que el clon de un repositorio vacío conducirá a esto. Quizás los repositorios vacíos no tengan HEAD porque no existe ningún objeto commit.

Puede utilizar el registro de git

--remotes --branches --oneline --decorate

para ver la diferencia entre cada repositorio, mientras que el "problema" no hacer tiene "origen/HEAD"

Editar: Dar una manera usando la línea de comandos
también puede utilizar la línea de comandos git para hacer esto, tienen el mismo resultado

git simbólico-ref árbitros/mandos a distancia/origen/HEAD árbitros/mandos a distancia/origin/master

+0

Correcto, parece que sí. Con ese archivo adicional me estoy perdiendo HEAD-branch. Lo hice en mi sistema Linux: 'echo" ref: refs/remotes/origin/master "> .git/refs/remotes/origin/HEAD'. Gracias invierno. – Dennis

+1

@Dennis: El resultado aquí es que 'origin' significa 'origin/HEAD', pero git es un poco dudoso acerca de la determinación del HEAD del origen. Los protocolos remotos en realidad no permiten la transferencia de referencias simbólicas, por lo que cuando se clona, ​​efectivamente le pide al control remoto SHA1 de HEAD, y luego se da cuenta de qué ref señala a esa confirmación. (Si hay varios, primero elige el maestro). Y la actualización remota y tal, en realidad, no toca los HEAD de los controles remotos, por lo que está trabado haciéndolo manualmente si no lo obtuvo cuando lo clonó. – Cascabel

+0

@Jefromi: me di cuenta de que el git es dudoso. Gracias por tu explicación. – Dennis