2012-03-08 26 views
5

Abbiamo un flusso di lavoro in cui il codice di commit deve essere esaminato da altri sviluppatori. In casi semplici questo può essere fatto con "git diff oldhash newhash> diff.txt" e caricarlo nella nostra bacheca di revisione.Strumento Git diff su più commit con l'altro commit tra

Ma c'è un modo per creare un diff su più commit ed escludere i commit fatti in mezzo da qualcun altro. Per esempio io voglio creare diff sopra mine1 a mine4 ma escludo Joe di commettere:

mine4 
mine3 
joe's 
mine2 
mine1 

Delle idee come fare questo in linea di comando git o con qualche altro strumento?

Modifica: i commit effettuati da altri riguardano file diversi dai miei commit, quindi in questo caso si tratta solo di escludere le modifiche apportate da altri.

+0

Questo non ha molto senso. 'mine4' dipende da' mine3', 'joe's' e' mine2' (e 'mine1' ovviamente) – knittl

+0

Può dipendere da quando si guardano gli oggetti di git ma possono toccare parti completamente indipendenti del codice sorgente. – Bombe

+0

@Bombe: potrebbe - o potrebbe non farlo. Non esiste una rappresentazione sensata se i commit intermedi sfiorano la stessa porzione di codice (inoltre, i file potrebbero essere spostati/rinominati) – knittl

risposta

5

si potrebbe ottenere questo attraverso la creazione di un nuovo ramo combinato con cherry-pick:

git checkout -b mine_diffs 
git cherry-pick mine1 
git cherry-pick mine2 
git cherry-pick mine3 
git cherry-pick mine4 
git diff mine1_ mine4_ 

Quando hai finito, basta eliminare il ramo. Si noti che gli hash sha1 saranno diversi quando si diffondono, che è ciò che indica mine1_ e mine4_.

3

Ok, forse non è vero, ma creerei un nuovo ramo, rimuoverò i commit non necessari e confrontò due rami.

4

Non sono abbastanza sicuro di cosa intendi per "over mine1 to mine4". I differenziali sono sempre a coppie (eccetto che per il mid-merge); "git diff mine1 mine4" ti darà tutti i cambiamenti tra questi due alberi. Dato l'esempio sopra, puoi ottenere quattro patch separate: mine1-> mine2, mine2-> joes, joes-> mine3, mine3-> mine4. Se hai fatto mine1-> mine2, mine2-> mine3, mine3-> mine4 avresti ancora "visto" le modifiche di joe.

Forse ciò che si desidera è (come suggerito da @OleksandrKravchuk) "un diff di quello che si avrebbe, se si selezionassero i cambiamenti in mio2, mio3 e mio4 in un ramo che partiva dal mio1". In tal caso, dovrai fare proprio questo: creare un tale ramo, selezionare le modifiche da applicare e quindi generare il diff.

Si potrebbe automatizzare questo abbastanza facilmente creando il ramo temporaneo e facendo la sequenza di "git cherry-pick", saltando il commit (s) che si desidera omettere.

1
  1. Rivedere un fascio di commit come una diff è cattivo stile: CodeReview (se utilizzato) deve lavorare sul singolo-commit livello
  2. Non si può avere diff "sparsi"
  3. forse la strumenti giusti saranno essere nel modo giusto? Per Git è Gerrit
+0

Riguardo a 1 - Ci sono sviluppatori che si impegnano e spingono spesso. Suppongo che abbiamo bisogno di istruirli per fare lo squash rebasing allora? –

+0

@PetteriHietavirta - il commit spesso è buono, ma non è correlato alla missione CodeReview - "commit good code".Impegni frequenti è un mal di testa del revisore, non codificatore –

+2

Il modo in cui facciamo revisioni con Git è che: (1) tutto lo sviluppo avviene in feature branch (2) uno sviluppatore per feature-branch (3) quando branch è pronto, è schiacciato e reimpegnato in modo che ogni patch rappresenti una minima unità logica di cambiamento (4) i rami vengono uniti insieme dopo il superamento della revisione. Vedi anche i documenti sul processo di sviluppo di Git (cioè sullo sviluppo di Git stesso). –