Perché git branch -t fallisce con "Non tracciare: informazioni ambigue"?

Question

Quando cerco di creare un nuovo ramo monitoraggio di un ramo a distanza, ottengo questo:

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

The source sembra per cercare in qualche modo di rami di monitorare e mi butta fuori perché trova meno più di uno, ma Non capisco esattamente cosa stia cercando dato che gli ho già detto cosa tenere traccia sulla linea di comando.

Qualcuno può dirmi cosa sta succedendo e come risolverlo?

Answer 1

Trovato! Il problema era che in precedenza avevo installato un telecomando con --mirror, allo scopo di avere una copia di backup/pubblica del mio repository.

Se si esegue

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

non unica bandiera il telecomando come specchio (che è quello che volevo per spinte), ma configura anche remote.<mirror>.fetch opzione per lo specchio a +refs/*:refs/*, il che significa che tutti i tuoi i rami improvvisamente "tracciano" il tuo repository mirror e qualsiasi tentativo di creare un ramo di monitoraggio fallirà.

(Come bonus aggiuntivo, l'esecuzione git fetch <mirror> sta per sovrascrivere tutti i vostri arbitri con quelli vecchi dal repo di backup.)

La soluzione che sembra risolvere questo problema sta mettendo remote.<mirror>.fetch-: (che, spero , significa "non recuperare mai nulla"). Questo a quanto pare risolve il problema di tracciamento ed elimina il recupero mortale.

Answer 2

perché trova meno di un

No: perché trova più di un corrispondente ramo remoto, il che significa che la funzione remote_find_tracking() restituisce ramo più di un monitoraggio per un determinato ref ramo locale.

È some_remote_branch non già rintracciato da una delle filiali locali?
(a git config -l consentirebbe di controllare ciò che si è attualmente impostato).
(un git branch -r può anche aiutare a elencare i vostri attuali filiali remote-tracking.)

---

filiali remote, che ho pensato sono qualcosa di diverso che filiali remote-tracking.

errato, come illustrati da this thread:

-remoti rami sono le remote-tracking-rami "reale". Non li impegni a livello locale, sono essenzialmente copie di sola lettura di esattamente ciò che accade in un repository remoto.
Se si prova a 'git-checkout' un ramo di localizzazione remota, si otterrà un HEAD distaccato.

filiale locale:
Un ramo al quale è possibile eseguire il commit delle modifiche. Facoltativamente, il ramo può essere configurato per "seguire" uno dei rami di tracciamento remoto. Ciò significa che un 'git-pull' senza argomenti (quando il tuo ramo locale è estratto), automaticamente 'git-fetch' e quindi 'git-merge' il ramo di localizzazione remota.

Ora:

è il lavoro di git-fetch per aggiornare in remoto il monitoraggio rami con tutte le modifiche presenti nel repository remoto.
Git-pull esegue git-fetch e quindi esegue un git-merge per aggiornare il ramo attualmente estratto.

Il problema è, per git-merge:

Quando questo accade, git-merge deve decidere quali remote-tracking-branch unire nel ramo locale attualmente controllato.
È possibile impostare quale remote-tracking-branch sarà selezionato in questa situazione con l'opzione --track.

--track istituisce un ramo locale di seguito per fare riferimento a ramo di un telecomando, non al ramo di monitoraggio

Consider thatremote_find_tracking() prende un unico telecomando e un refspec con src pieno, e restituisce la data refspec dopo riempiendo il suo dst, se è stato configurato un monitoraggio appropriato per il telecomando, ovvero 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); 

Può essere che si consideri già un ramo successivo locale corrispondente a some_remote_branch. Avete qualche filiale locale con lo stesso identico nome?
Oppure il tuo ramo corrente ha un ramo remoto con un nome simile, che lo rende un candidato naturale per qualsiasi git-merge: cercando di farlo rintracciare un altro ramo remoto renderebbe il non in grado di scegliere quale locale ramo per aggiornare/unire con le modifiche di un telecomando.

Answer 3

L'ho visto anche quando avevo due repo remoti con lo stesso schema (predefinito) di recupero (fetch = +refs/heads/*:refs/remotes/origin/*) e gli stessi rami.

non ho ancora trovato il modo di risolvere in modo corretto, perché voglio continuare a spingere/tirare per entrambi i pronti contro termine di, ma aggiungendo manualmente le informazioni per .git/config opere del progetto, esempio:

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

Answer 4

Sono entrato in una situazione come questa, ma non so come. L'elenco da git branch -av mi ha mostrato solo un singolo ramo di monitoraggio remoto per il ramo a cui tenevo (origin/dev).

Quello che ho fatto per risolvere il problema è stato quello di utilizzare l'esadecimale commettere hash invece di origin/dev:

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

Quando ho fatto la spinta con -u Git ha detto Branch dev set up to track remote branch dev from origin. tira successivi e spinge lavorato come mi aspettavo.