2014-07-23 11 views
14

Vorrei evitare di chiamare i comandi di porcellana dai miei script, ma c'è un modo per ottenere un po 'del comportamento di git checkout <commit> usando solo comandi idraulici come checkout-index? Sono particolarmente interessato all'effetto sulla copia di lavoro: supponendo che tutto sia pulito, elimina i file tracciati nel vecchio HEAD e assenti in quello nuovo. checkout-index non sembra avere alcun concetto di eliminazione dei file. La cosa più vicina che posso pensare sarebbe chiamareCome replicare git-checkout usando solo i comandi idraulici?

git diff-tree -p <old> <new> | git apply 

ma calcolare l'intera diff sembra inutilmente costoso. C'è un modo migliore?

+3

Qualsiasi motivo per cui non si chiama semplicemente git checkout ... '? –

+0

Sì, non rendere la vita inutilmente difficile. – ThiefMaster

+1

In definitiva voglio avere più controllo su come avviene il checkout. Ad esempio, 'checkout' può cancellare file ignorati, e voglio evitare di farlo (maggiore sicurezza). Ma voglio spianare i file cancellati (riduzione della sicurezza), senza usare '--force' per spianare tutto. Questo fa parte di uno script che sta usando git sotto le copertine per archiviare gli alberi dei file, e 'checkout' è molto vicino a come voglio che il mio script si comporti, ma non del tutto. Ho pensato che se potessi ottenere 'checkout' con i comandi idraulici potrei modificarlo da lì, anche se per favore fammi sapere se c'è un altro modo per ottenere questo controllo. –

risposta

9

Stai cercando the two-tree git read-tree -um. Utilizza un albero di base, (in genere lo si alimenta con lo HEAD), un albero di destinazione e (implicitamente) l'indice e l'albero di lavoro. Il tavolo che descriveva il suo comportamento era difficile da capire, quindi ho il mio cheatheet per questo, uno riformattato che ha più senso per me, comunque. Ad ogni modo, implementa git checkout.

git read-tree -um H M # `I` is the (implicit) index, GIT_INDEX_FILE 

        Legend 

     H  Original tree (usually HEAD:) 
     I  Indexed tree 
     M  Merge target tree 

     H->I  \ 
     H->M  } status in second relative to first 
     I->M /

     "-"  file exists in neither 
     new  exists only in second 
     deleted exists only in first 
     same  exists in both, unchanged 
     changed exists in both, different 
     (blank) irrelevant or all cases not otherwise given 

     keep keep current version 
     fail whole command fails, no changes 
     delete delete worktree file 


     H->I  H->M  I->M 

          same  keep 

    deleted changed    fail 
    deleted deleted    delete 
    deleted same    delete unless Index empty, else use M 
       same    keep 

     same  changed    worktree clean: use M; dirty: fail 
     same  deleted    worktree clean: deleted; dirty: fail 

     new  -     keep 
     new  new  changed fail 
    changed changed changed fail 
    changed deleted    fail 


note: "index empty" identifies an initial checkout, where HEAD has been 
set but never loaded. git can't currently distinguish between a 
delete-everything index and an initial-checkout index. 
+0

+1. Mi piace il cheatsheet. Ho completato la mia risposta con un esempio usando 'git read-tree -um'. – VonC

+0

Grazie! Non avrei mai immaginato. –

+0

Prego. Non l'avrei nemmeno indovinato, non è sempre facile vedere cosa si può ottenere da fare. So di non aver ottenuto questo comando fino a quando non sono diventato matto al tavolo del doc e ho speso il tempo per crearne uno mio. – jthill

Problemi correlati