Confronto delle differenze attraverso un rebase in Git

Question

Supponiamo che ho appena ribasato il ramo foo su master, con conflitti. Voglio assicurarmi di non danneggiare accidentalmente il contenuto di foo durante la risoluzione dei conflitti introducendo modifiche extra o perdendo le modifiche (oltre a quelle appropriate per la risoluzione dei conflitti). Ho fatto questo tramite:

diff -u <(git diff `git merge-base master foo@{1}` foo@{1}) \ 
     <(git diff `git merge-base master foo ` foo ) 

(aggiornamento: o l'equivalente ... sintassi per git-diff che ho appena ricordato :)

diff -u <(git diff master...foo@{1}) <(git diff master...foo) | mate 

Questo mi mostra tutti i cambiamenti che si sono verificati a master..foo considerato come una patch, che è esattamente quello che voglio controllare per essere minimo. Tuttavia, l'invocazione è complessa e l'output non è del tutto semplice da interpretare.

Esiste un modo migliore per eseguire questa attività: fornire le stesse informazioni, ma con un metodo o un formato migliore, oppure devo semplicemente prendere quanto sopra e racchiuderlo in uno script?

Answer 1

Differenze tra master e foo ricalcolato:

git diff master..foo

vs.

differenze di pre-rebase foo dopo dirama master (nota tre punti):

git diff master...foo@{1}

?

Answer 2

Poiché si tratta di rebase e non di un'unione, è possibile confrontare foo con se stesso ma prima dell'unione. Se ricordo correttamente, foo@{1} produrrà il genitore del commit corrente per foo, e forse questo non è quello che stai cercando.

Penso che si possa fare qualcosa di simile alla seguente (supponendo che non avete fatto un git gc):

Sul ramo foo dopo il rebase:

$ git reflog 

questo mostrerà come la testa del ramo è stato spostato Si dovrebbe vedere alcuni record come questo (a seconda se si rebase interattivo o meno):

64d3c9e HEAD@{15}: rebase -i (finish): returning to refs/heads/master 
64d3c9e HEAD@{16}: rebase -i (fixup): Fixes external dependencies 
049169e HEAD@{17}: rebase -i (fixup): updating HEAD 
d4c2e69 HEAD@{18}: rebase -i (pick): Fixes external dependencies 
049169e HEAD@{19}: rebase -i (fixup): Imports futures 
e490bed HEAD@{20}: rebase -i (fixup): updating HEAD 
... 
etc 
... 

guardare avanti per la ultimo dei commit foo prima della fusione. A seconda di ciò che hai fatto, potrebbe essere difficile o no. Questo è il motivo per cui non ho fornito un copione fai-da-te.

Raccogliere l'ID di commit che ha l'ultimo commit per foo prima del rebase e quindi confrontare con quell'ID di commit. Dire che Commit ID è: XXXX:

git diff XXXX...foo 

Forse è questo ciò che si desidera.

Answer 3

Un approccio leggermente diverso: Git ha un buon supporto per mostrarlo nel caso di unioni. cioè"cosa è cambiato rispetto a parent-1 che non può essere spiegato da parent-2?"

ci sono un paio di modi si potrebbe sfruttare tale supporto per il vostro rebase:

Opzione 1:

1. fare una rimessa via merge prima (al posto di un rebase). Quindi il normale display di fusione mostrerà cosa è stata cambiata la fusione. Controlla questo è quello che volevi.

2. Torna indietro e rebase e confronta il suggerimento rebasato con il risultato della fusione: devono essere identici.

Opzione 2 (se rebasing è più facile che la fusione):

1. fare il rebase.
2. Utilizzare un innesto per renderlo simile a un'unione localmente/temporaneamente.

Per fare questo, creare un .git/informazioni/innesti con una sola riga:

TIP UPSTREAM OLDTIP 

Dove TIP è l'ID commit del ramo ricalcolato e gli altri sono i due genitori desiderati (vale a dire le due cose che avresti fuso, se avessi fatto una fusione). Quindi esaminalo come se fosse una vera fusione.

Non sono sicuro di automatizzarlo; Tendo a fare queste cose con gitk open, perché rende facile confrontare le revisioni giuste (usando il menu del tasto destro del mouse).

Se si desidera confrontare due diffs, è possibile che si desideri esaminare l'interdiff (1), ma non sono sicuro di quanto possa gestire i file di base in modo diverso.

Answer 4

git-cherry cerca i commit su un ramo che non sono su un altro. Devi usare come:

git cherry -v OLDTIP TIP UPSTREAM 

vale a dire cercare i commit che erano sul OLDTIP ma che non sono in UPSTREAM..TIP. Osserva la firma della patch per vedere se è inclusa una patch, quindi se una patch viene aggiunta, eliminata o modificata durante il rebase, verrà visualizzata nell'elenco. Le cose che sono state applicate senza modifiche non appariranno.

Un effetto simile può essere ottenuto tornando a OLDTIP e facendo git rebase -i TIP, poiché utilizza la stessa logica per popolare l'elenco di commit.

Answer 5

Quello che vogliamo veramente mostrare è il conflitto combinato diff che viene generato come se avessimo fatto una fusione per ottenere da (a) a (b) dove (a) era precedentemente basato su (upstream-old) e (b) è ora basato su (upstream-new).

Non vogliamo solo una differenza diretta.

Invece, possiamo essenzialmente fare l'unione ma forzare l'albero risultante ad essere $ b^{tree} che sappiamo già essere il punto di "fine" corretto di ciò che vogliamo.

Più o meno, supponiamo che abbiamo

newcommit -> the new version of the series 
oldcommit -> the old version of the series 
upstream -> the (new) version of the base of the series 

possiamo generare l'unione tramite

git commit-tree newcommit^{tree} -p oldcommit -p upstream -m "message" 

e poi mostrare il risultato con "git show" e questo genererà un diff combinato formato che mostra tutti i bit necessari come risoluzione dei conflitti che ignora automaticamente le modifiche che non erano in realtà parte della risoluzione dei conflitti.

funziona questo anche per semplice ammending un cambiamento così, e si può fare un po 'più di lavoro per garantire che l'unione generato commettere dispone autore precisa e impegnarsi timestamp in modo che sia coerente su più chiamate (dal momento che siamo memorizzazione un libero riferimento nel database degli oggetti).

Purtroppo non sono stato in grado di capire come ottenere semplicemente "git diff" per diff allo stesso modo senza generare effettivamente un albero ancora. Non sono sicuro di quali argomenti dovremmo passare per arrivare a quel punto.