2015-03-11 12 views
7

Sono in una situazione in cui alcune modifiche apportate in un ramo di funzionalità non si riflettono nel master, anche se questo ramo è stato fuso in esso. Non riesco a capire perché. Per semplicità, diciamo che questa commettere ha un hash "A" e "file" modificato il filecommit "mancante"

Questo può probabilmente essere meglio illustrata dai seguenti comandi:

$ git checkout master 

$ git branch --contains A 
* master 
feature_branch 

$ git log file | grep A 
(no output) 

$ git checkout feature_branch 

$ git log file | grep A 
A 

Qualcuno può spiegare cosa sta succedendo qui? Ancora più importante, c'è qualcosa che può essere fatto per prevenire questo in futuro?

EDIT:

Come accennato da poche persone, il seguente evidenziavano il commit:

$ git checkout master 

$ git log --follow file | grep A 
A 

Ma la cosa è ... il file è stato non rinominato. In modo che non spiega completamente le cose, sia ..

+1

Quale output, se esiste, si ottiene se si esegue 'git log A..master'? – Jubobs

+0

Come ti sei unito? L'unione può riscrivere i commit (ad esempio lo squash). –

+0

C'è uscita. Un sacco di risultati. Questo particolare commit è stato effettuato più di un mese fa .. è stato solo recentemente portato alla mia attenzione che non si è riflesso nel master. –

risposta

0

Se in qualche modo la posizione del file è stato modificato, potrebbe essere necessario dire git log-follow:

$ git checkout master 
$ git log --follow -- file | grep A 

Si può verificare se c'è una differenza tra git log --oneline -- file e git log --oneline --follow -- file, per vedere se il file è stato riposizionato.

+0

Non credo che la posizione del file sia cambiata. Ma ho eseguito il comando comunque, solo per vedere cosa sarebbe successo .. e sorprendentemente (scioccante) ecco ed ecco, c'è il commit mancante .. –

+0

@Gauthier - pensa che ci sia un errore di battitura lì: '--online' - -> '--oneline'? – KazR

4

Sei vittima di un'unione malefica.

Ecco come riprodurre lo

git init testrepo 
cd testrepo 

touch initial 
git add initial 
git commit -m 'initial commit' 

git checkout -b feature_branch 
echo "A" >> file 
git add file 
git commit -m 'file committed' 

git checkout master 

Ora fare un merge interattivo come se ci fosse unire conflitti

git merge --no-commit --no-ff feature_branch 

e spostare il file file (male merge).

testrepo (master|MERGING) 

git mv file someOtherFile 
git commit 

Ora si vedrà che il Maestro ramo contiene il commit (nel mio caso 9469682), che ha introdotto il file file

git branch --contains 9469682 
    feature_branch 
* master 

Ma un git log non mostrerà, perché è stato spostato

git log -- file 
(no output) 

Usa

git log --follow -- file 

e il commit appare di nuovo.

Ricorda inoltre che l'unione può ottenere più malvagità. Se anche il contenuto dello file è cambiato molto rispetto a èven, lo git log --follow non lo rileverà, a causa della soglia di rinomina.

In questo caso utilizzare git log --follow --find-renames= per regolare la soglia di rinomina.

Se la generazione di diff, rilevare e segnalare rinomina per ogni commit. Per i seguenti file durante la rinomina mentre si attraversa la cronologia, vedere - seguire. Se n è specificato, si tratta di una soglia sull'indice di similarità (cioè quantità di addizione/cancellazione rispetto alla dimensione del file). Ad esempio, -M90% significa che Git dovrebbe considerare che una coppia di eliminazione/aggiunta debba essere rinominata se oltre il 90% del file non è stato modificato. Senza un segno%, il numero deve essere letto come una frazione, con un punto decimale prima di esso. I.e, -M5 diventa 0,5 ed è quindi uguale a -M50%. Allo stesso modo, -M05 è uguale a -M5%. Per limitare il rilevamento a nomi esatti, utilizzare -M100%. L'indice di somiglianza predefinito è 50%.

+0

Il fatto è che questi file non sono stati rinominati. Mi sono appena reso conto di * un altro * commit da un altro ramo di funzionalità che mostrava lo stesso problema. –