Git rebase --continua a lamentarsi anche quando tutti i conflitti di unione sono stati risolti

Question

Sono di fronte a un problema che non so come risolvere.

ho fatto un rebase contro il padrone del mio ramo:

git rebase master 

e ottenuto il seguente errore

First, rewinding head to replay your work on top of it... 
Applying: checkstyled. 
Using index info to reconstruct a base tree... 
Falling back to patching base and 3-way merge... 
Auto-merging AssetsLoader.java 
CONFLICT (content): Merge conflict in AssetsLoader.java 
Failed to merge in the changes. 
Patch failed at 0001 checkstyled. 

Così sono andato al mio editor preferito, fissa il conflitto 1 linea, salvato il file e ha ottenuto uno stato git e ottenuto il seguente risultato:

# Not currently on any branch. 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
# modified: PassengerContactHandler.java 
# 
# Unmerged paths: 
# (use "git reset HEAD <file>..." to unstage) 
# (use "git add/rm <file>..." as appropriate to mark resolution) 
# 
# both modified:  AssetsLoader.java 
# 

Ho fatto un git add AssetsLoader .java e uno status git ed ha ottenuto la seguente:

# Not currently on any branch. 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
# modified: AssetsLoader.java 
# modified: PassengerContactHandler.java 
# 

e quando ho fatto git rebase --continue ottengo:

git rebase --continue 
You must edit all merge conflicts and then 
mark them as resolved using git add 

so di poter ignorare la patch e continuare la rebase, ma Non sono sicuro che le modifiche in PassengerContactHandler.java verranno ridistribuite nel mio ramo o meno.

quindi non sono sicuro, come devo procedere?

Modifica: Potrebbe essere che il file con il conflitto risolto sia esattamente come la versione originale?

Grazie mille, Lucas

Edit, è successo e basta a me ancora una volta:

E 'successo di nuovo a me,

(307ac0d...)|REBASE)$ git status 
# Not currently on any branch. 
# Changes to be committed: 
# (use "git reset HEAD <file>..." to unstage) 
# 
# modified: assets/world/level1/Level-1.xml 
# modified: George.java 
# modified: DefaultPassenger.java 
# 
# Untracked files: 
# (use "git add <file>..." to include in what will be committed) 
# 
# mb-art/originalAssets/27dec/ 

((307ac0d ...) | REBASE) $ git rebase --continue

You must edit all merge conflicts and then 
mark them as resolved using git add 

git --version

git version 1.7.1 

Answer 1

Hai perso un conflitto di unione in AssetsLoader.java. Aprilo e cerca i marcatori di conflitto (">>>>", "====", " <") e poi fai di nuovo il comando git add. Fai un 'git diff --staged' se hai difficoltà a trovarlo.

Answer 2

Prova l'esecuzione di questo nella riga di comando:

$ git mergetool 

dovrebbe portare un editor interattivo che consente di risolvere i conflitti. Più facile di provare a farlo manualmente, e anche Git riconoscerà quando si effettua l'unione. Eviterà inoltre situazioni in cui non ti unisci completamente per sbaglio e ciò può accadere quando provi a farlo manualmente.

Answer 3

Ive ha appena avuto questo problema, e mentre penso che ci potrebbero essere alcune cause, ecco la mia ...

ho avuto un git pre-commit hook che ha respinto impegna a determinate condizioni.Questo va bene quando si commette manualmente, dal momento che visualizzerà l'output del gancio, e posso ripararlo o scegliere di ignorarlo usando commit --no-verify.

Il problema sembra essere che quando rebasing, rebase --continue chiamerà anche il hook (per commettere l'ultimo bout di modifiche). Ma rebase non visualizzerà l'output hook, vedrà solo che non ha funzionato, e quindi sputerà un errore meno specifico dicendo 'Devi modificare tutti i conflitti di merge e poi contrassegnarli come risolti usando git add'

Per risolvere metti in scena tutte le tue modifiche e invece di fare 'git rebase --continue', prova un 'git commit'. Se si soffre dello stesso problema con l'hook, dovresti quindi vedere i motivi del suo fallimento.

È interessante notare che, sebbene git rebase non visualizzi l'output da git hook, accetta un --no-verify per ignorare i hook.

Answer 4

Seems to be a bug in Git 1.7

Here's a good article on how to solve this.

Fondamentalmente si dovrebbe funzionare, se si fa un

git diff 

dopo aver risolto i tuoi conflitti e quindi

git rebase --continue 

dovrebbe funzionare.

Answer 5

Ciò accade perché durante il fixing di un conflitto, è stato rimosso tutto il codice nella patch che si applicava al ramo su cui si sta riposizionando. Utilizzare git rebase --skip per continuare.

un po 'più particolari:

Normalmente, nel fissare un conflitto durante il ribasamento, verrà modificato il file in conflitto, mantenendo una parte o tutto il codice nella patch attualmente applicato al ramo si rebase su . Dopo aver fissato la patch e facendo

git add your/conflicted/file 
git status 

si otterrà una linea (di solito verde) che mostra il file modificato

modificato: il tuo/file/conflitto

git rebase --continue funzionerà bene in questa situazione.

A volte, tuttavia, quando si risolve il conflitto, si rimuove tutto nella nuova patch, mantenendo solo il codice dal ramo su cui si è basato. Ora quando aggiungi il file, sarà esattamente come quello su cui hai provato a rebase. lo stato di git non mostrerà nessuna linea verde che mostra i file modificati. Ora, se non

git rebase --continue 

git si lamenterà con

Nessuna modifica - lo si dimentica di usare 'git add'?

Cosa git vuole realmente di fare in questa situazione è quello di utilizzare

git rebase --skip 

di saltare la patch. In precedenza non l'ho mai fatto, dato che non ero sicuro di cosa sarebbe saltato in realtà se l'avessi fatto, non era ovvio per me cosa intendesse dire "saltare questa patch". Ma se si ottiene alcuna linea verde con

modificato: il vostro/conflitto/file di

dopo aver modificato il file in conflitto, l'aggiunta di esso, e facendo git status, allora si può essere abbastanza sicuro che è stata rimossa la patch intera, ed è invece possibile utilizzare

git rebase --skip 

continuare.

Il post originale ha detto che questo a volte funziona:

git add -A 
git rebase --continue 
# works magically? 

... ma non si basano su questo (ed essere sicuri di non aggiungere file rimasti nelle cartelle del repository)

Answer 6

Dopo aver risolto il conflitto, assicurarsi che i file modificati siano aggiunti ai file di staging. Questo ha risolto il problema per me.