git subtree pull dice che l'albero di lavoro ha delle modifiche, ma lo stato di git dice che non funziona. Cosa dà?

git subtree pull --prefix=frameworks/AquaticPrime --squash AquaticPrime

ottengo questo:

Working tree has modifications. Cannot add.

Se faccio questo (nello stesso luogo, ovviamente):

git status

Ho ottenuto questo:

# On branch master 
nothing to commit (working directory clean)

Non sono sicuro di cosa sta succedendo qui. Il comando git status implica che non ho modifiche, quindi presumo che il pull secondario di git faccia riferimento a modifiche in un ramo diverso relativo alla sottostruttura, ma non è completamente chiaro.

Qualcuno può fornire l'illuminazione?

fonte

2010-09-02 Sam Deane

Da un rapido sguardo alla fonte, 'stampe git-subtree' che quando' git diff-index TESTA --exit-code - quiet' esce dal "fallimento", cioè i cambiamenti esistono. Cosa succede se si esegue 'git diff-index HEAD'? – Cascabel

Si potrebbe anche provare l'opzione '-d' (debug). – Cascabel

Quando eseguo git diff-index HEAD, ottengo "fatale: argomento ambiguo 'HEAD': revisione sconosciuta o percorso non presente nell'albero di lavoro.". Uscita simile se uso il flag -d debug. Quindi la domanda è: perché la TESTA sarebbe sconosciuta? –

-4

Provare a tirare senza --squash come descritto in this stackoverflow question.

fonte

2012-06-11 09:43:22

Grazie, mi sento un po 'maleducato non alzando il voto/ticchettando la tua risposta, ma la verità è che è passato così tanto tempo che non lo faccio usa la sottostruttura di più, e non posso davvero testare la risposta per vedere se funziona! –

Ho lo stesso problema e rimuovere --squash non lo risolve. – Alkaline

Per prima cosa non ho usato lo squash. In effetti non so nemmeno perché penseresti che funzionerebbe perché la domanda SO che hai postato non chiedeva del messaggio che stiamo ricevendo .. –

Ho capito questo ora. Il mio problema mi sembrava che il deposito fosse nuovo di zecca: non avevo mai commesso nulla. Una volta che ho effettuato il commit di un file sul repository, sono riuscito a superare questo errore.

Tuttavia, utilizzando il comando git subtree add C:\gitTest\repos\subA -d --prefix subA ho ottenuto il nuovo errore:

fatal just how do you expect me to merge 0 trees?

Dopo fare in giro per un minuto, ho capito che richiede che una revisione specifica essere passato a esso. Quindi questo comando sembra aver avuto successo:

git subtree add C:\gitTest\repos\subA HEAD -d --prefix subA

E ovviamente non è necessario il flag di debug -d.

fonte

2013-05-28 02:01:48

Grazie ** very ** much !! La tua osservazione relativa ai problemi con il repository vuoto si è rivelata valida anche nel contesto di [questa domanda sui problemi con 'git tfs subtree add'] (http://stackoverflow.com/questions/25886008/how-to-manage-two -tfs-progetti-in-un-git-repository/38081315 # 38081315). Il messaggio di errore esatto era 'fatale: argomento ambiguo 'HEAD': revisione sconosciuta o percorso non presente nell'albero di lavoro. Si trattava di" missing HEAD "sul master in repository vuoto. – quetzalcoatl

Ho appena avuto lo stesso problema. Dalla sorgente GIT, viene generato un errore quando il comando git diff-index HEAD restituisce il risultato, anche se git status dice che l'albero di lavoro è pulito.

Per evitare questo errore, nel mio caso, ho ri-checkout il ramo corrente di albero di lavoro, e tutto sembra OK: git checkout <branch>

E 'un po' confuso, ma se qualcuno può spiegare perché ...

fonte

2013-09-04 08:07:07 Koryonik

La descrizione del problema è ottima, ma ho bisogno di un po 'più di informazioni per implementarlo ... OH, intendevi semplicemente eseguire "git checkout master" nel modulo principale (non sottostrato). Grande! –

Grazie, funziona come un fascino! –

ho appena avuto questo problema, quando ho:

aggiunto un sotto-albero;
realizzato, l'ho aggiunto in modo errato (a una directory errata);
rimosso con rm;
ha tentato di importarlo nuovamente (nella posizione corretta).

Anche se puppet diff era - correttamente - che mostra nulla, il git diff-index HEAD elencati ciascuno dei file che ho appena cancellato come "cancellato" - anche se non ho mai commesso-ed (e tanto meno push-ndr) nulla.

credo, questo è un bug in git (utilizzando 2.7.0 qui) ... bug o no, il work-around è quello di passare a qualsiasi altra ramo (con la solita git checkout ....) e poi di nuovo a il tuo. Spero, questo aiuti qualcuno - anche se non il richiedente originale.

fonte

2016-04-14 18:51:54

git reset --hard fissata a me

Da git reset --help

--hard Resets the index and working tree. Any changes to tracked files in the working tree since are discarded.

fonte

2016-08-19 11:40:03 Anssi

git subtree pull dice che l'albero di lavoro ha delle modifiche, ma lo stato di git dice che non funziona. Cosa dà?

risposta

Problemi correlati