¿Por qué git branch -t falla con "No seguimiento: información ambigua"?

Cuando bash crear una nueva twig que rastrea una twig remota, obtengo esto:

$ git branch -t test origin/foo error: Not tracking: ambiguous information for ref refs/remotes/origin/foo 

La fuente parece de alguna manera search twigs para rastrear y arrojarme porque encuentra Menos más de uno, pero no obtengo exactamente lo que busca porque ya le dije qué hacer en la línea de command.

¿Alguien puede decirme qué está pasando y cómo solucionarlo?

Vi esto también cuando tenía dos repo remotos con el mismo patrón de búsqueda (pnetworkingeterminado) ( fetch = +refs/heads/*:refs/remotes/origin/* ) y las mismas twigs.

Todavía no he resuelto cómo solucionarlo correctamente, ya que quiero continuar presionando / jalando a ambos repositorys, pero manualmente agregando la información a los trabajos de .git/config del proyecto, por ejemplo:

 [branch "mybranch"] remote = origin merge = refs/heads/mybranch 

porque encuentra less de uno

No: porque encuentra más de una twig remota coincidente, lo que significa que la function remote_find_tracking() devuelve más de una twig de seguimiento para una ref local de una twig determinada.

¿ some_remote_branch no ha sido rastreado por una de sus sucursales locales?
(una git config -l le permitiría verificar lo que tiene configurado actualmente).
(Una git branch -r también puede ayudar a enumerar sus twigs actuales de seguimiento remoto).


sucursales remotas, que pensé que eran algo diferente que las sucursales de seguimiento remoto.

Incorrecto, como lo ilustra este hilo :

las sucursales remotas son las "reales" sucursales de seguimiento remoto. No se compromete con ellos localmente, son esencialmente copys de solo lectura de exactamente lo que está sucediendo en un repository remoto.
Si intenta 'git-checkout' una twig de seguimiento remoto, obtendrá un HEAD separado.

Sucursal local:
Una twig a la que puedes enviar cambios. Opcionalmente, la sucursal se puede configurar para "seguir" una de sus sucursales de seguimiento remoto. Esto significa que un ' git-pull ' sin arguments (cuando su twig local está desprotegida), automáticamente ' git-fetch ' y luego ' git-merge ' la twig de seguimiento remoto.

Ahora:

es tarea de git-fetch actualizar las twigs de rastreo remoto con cualquier cambio que se encuentre en el repository remoto.
Git-pull ejecuta git-fetch y luego ejecuta un git-merge para actualizar la twig actualmente pagada.

El problema es, para git-merge:

Cuando esto sucede, git-merge debe decidir qué remote-tracking-branch fusionará con la twig local actualmente desprotegida.
Puede establecer qué remote-tracking-branch se seleccionará en esta situación con la opción –track.

--track configura una siguiente twig local para referirse a la twig de un control remoto, no a la twig de seguimiento

Considere que remote_find_tracking() toma un solo control remoto y un refspec con src lleno, y devuelve el refspec dado después de llenar su dst, si se configuró un seguimiento apropiado para el control remoto, es decir, git.

 /* * For the given remote, reads the refspec's src and sets the other fields. */ int remote_find_tracking(struct remote *remote, struct refspec *refspec); 

Puede ser que considere que ya tiene una twig de seguimiento local que coincida con some_remote_branch . ¿Tienes alguna sucursal local con ese mismo nombre?
O al revés: su twig actual tiene una twig remota con un nombre similar, lo que lo convierte en un candidato natural para cualquier git-merge : tratar de hacer que rastrear otra twig remota haría que la git-merge no pueda elegir qué local twig para actualizar / combinar con los cambios de un control remoto.

¡Lo tengo! El problema fue que previamente configuré un control remoto con --mirror , con el propósito de tener una copy de respaldo / pública de mi repository.

Si tu corres

 git remote add --mirror <name> <url> 

no solo marca el control remoto como espejo (que es lo que yo quería para los empujes), sino que también configura remote.<mirror>.fetch opción remote.<mirror>.fetch para el espejo a +refs/*:refs/* , lo que significa que todas sus twigs de repente "rastrea" su repository espejo y cualquier bash de crear una twig de seguimiento va a fallar.

(Como una ventaja adicional, al ejecutar git fetch <mirror> se sobrescribirán todas las references con las anteriores de su repository de copy de security).

La solución que parece solucionar este problema es configurar remote.<mirror>.fetch en : (lo que, espero, significa "nunca recuperar nada"). Esto aparentemente soluciona el problema de rastreo y elimina la búsqueda mortal.

Me metí en una situación como esta, pero no sé cómo. El listdo de git branch -av me mostró solo una única twig de seguimiento remoto para la twig que me interesaba ( origin/dev ).

Lo que hice para solucionarlo fue utilizar el hash de confirmación hexadecimal en lugar del origin/dev :

 git checkout -b dev abc123 git push -u origin dev 

Cuando hice el push con -u Git, dijo Branch dev set up to track remote branch dev from origin. Los tirones y empujes posteriores funcionaron como esperaba.