Git rebase conflitto con nulla da unire?

Question

Che cosa significa quando un re git trova un conflitto, ma non c'è nessun problema apparente nel file? Il file in questione non ha contrassegni di conflitto e git mergetool dice "nulla da unire".

Le opzioni che ho sono resettare o aggiungere:

# Unmerged paths: 
# (use "git reset HEAD <file>..." to unstage) 
# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 
# both modified:  filename.js 

Come faccio a sapere che cosa si tratta e quale strada prendere?

git ls-files -s filename.js dà 3 righe:

100644 d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 1 filename.js 
100644 9010798f1d19ac712196b1fc9b0870fd332b1275 2 filename.js 
100644 b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 3 filename.js 

Secondo la fine manuale, questo comando ci dice che le modalità di bit, il nome dell'oggetto, e il numero di fase. I bit di modalità sono gli stessi. Quindi cosa sono 1, 2 e 3, e perché sono "entrambi modificati", ma non mostrano marcatori di conflitto?

Answer 1

Le versioni nell'indice contrassegnati 1, 2, e 3 hanno il seguente significato:

1. il file come si era in un antenato comune delle due commit che stai fusione.
2. Il file com'era in HEAD, ad esempio il commit corrente quando è stata eseguita l'unione.
3. Il file così com'è nel commit che si sta tentando di unire in HEAD.

La mia fonte per questa informazione è the git manual's useful section on resolving conflicts.

L'uscita both modified in git status indica, ovviamente, che il file è stato modificato in modi diversi dai due commit che si stanno unendo dal loro antenato comune.

È piuttosto misterioso per me perché non si vedano i contrassegni di conflitto nel file, tuttavia - che i BLOB hanno nomi di oggetto diversi (hash) nell'output di git ls-files -s indica che byte per byte hanno sicuramente contenuto diverso. Se sei soddisfatto del file così com'è nella tua copia di lavoro, puoi semplicemente fare git add filename.js e poi git rebase --continue. Tuttavia, in ogni caso, potresti voler scoprire quali fossero queste differenze. Per fare questo, vorrei provare il seguente:

git diff :2:filename.js filename.js 

... che mostrerà le differenze tra la versione in HEAD e la vostra copia di lavoro corrente. Allo stesso modo, si può provare:

git diff :3:filename.js filename.js 

... Per vedere la differenza tra la versione in che veniva fuso e la vostra copia di lavoro.

Answer 2

Il 1, 2 e 3 di git ls-files -s rappresenta la "fase" di un 3-way merge: 1 è l'antenato comune, 2 è il capo diramazione corrente e 3 è l'altra HEAD ramo.Su Linux, puoi provare i seguenti comandi per vedere cosa c'è di diverso tra i file:

$ git cat-file blob d2c915b1d632b8ef8fbcf056824fb7fac7824ab9 | xxd -ps 
$ git cat-file blob 9010798f1d19ac712196b1fc9b0870fd332b1275 | xxd -ps 
$ git cat-file blob b3ab7ec50812c73a3ec97bf0985f3226ec13cbc8 | xxd -ps