Git rebase - kontynuuje narzeka nawet wtedy, gdy wszystkie konflikty zostały rozwiązane.

Question

Mam do czynienia z problemem, który nie jestem pewien, jak rozwiązać.

Zrobiłem rebase wobec pana z mojego oddziału:

git rebase master 

i mam następujący błąd

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. 

więc poszedłem do mojego ulubionego edytora, stałe konflikt 1 linia, zapisany plik i uzyskałem status git i otrzymałem następujące dane wyjściowe:

# 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 
# 

Zrobiłem git dodać AssetsLoader .java i git status i mam następujące:

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

i kiedy zrobiłem git rebase --continue uzyskać:

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

wiem, że mogę pominąć poprawkę i kontynuować rebase, ale Nie jestem pewien, czy zmiany w PassengerContactHandler.java zostaną ponownie wprowadzone do mojego oddziału, czy nie.

więc nie jestem pewien, jak powinienem kontynuować?

Edycja: Czy plik z rozstrzygniętym konfliktem może być identyczny z oryginalną wersją?

dziękuję, Lucas

Edycja, po prostu zdarzyło mi znowu:

To właśnie zdarzyło mi się raz,

(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

Brakowało konfliktu scalania w AssetsLoader.java. Otwórz go i poszukaj znaczników konfliktu (">>>>", "====", "< < < < <"), a następnie ponownie wykonaj git. Zrób "git diff --staged", jeśli masz trudności ze znalezieniem go.

Answer 2

Spróbuj uruchomić to w wierszu poleceń:

$ git mergetool 

powinien wychować interaktywny edytor pozwala rozwiązywać konflikty. Łatwiejsze niż próby zrobienia tego ręcznie, a także git rozpozna, kiedy wykonujesz scalenie. Unika także sytuacji, w których nie nastąpi całkowite scalenie przez przypadek, które może się zdarzyć, gdy spróbujesz zrobić to ręcznie.

Answer 3

Ive właśnie miał ten problem, a jednocześnie myślę, że może być kilka przyczyn, oto mój ...

miałem git pre-commit, który odrzucił zobowiązuje pod pewnymi warunkami.To jest w porządku, gdy wykonujesz ręcznie, ponieważ wyświetli wyjście haka i mogę go naprawić lub zignorować za pomocą commit --no-verify.

Problem polega na tym, że przy ponownym zakładaniu, rebase --continue również wywoła hak (aby zatwierdzić ostatnią próbę zmian). Ale rebase nie wyświetli wyniku hook, zobaczy tylko, że się nie udało, a następnie wypluwa mniej konkretny błąd: "Musisz edytować wszystkie konflikty scalania, a następnie oznaczyć je jako rozwiązane za pomocą git add"

Aby naprawić to, scenie wszystkie zmiany, i zamiast robić "git rebase --continue", spróbuj "git commit". Jeśli cierpisz na ten sam problem z hakiem, powinieneś zobaczyć przyczyny jego niepowodzenia.

Co ciekawe, podczas gdy git rebase nie wyświetla wyniku z git hook, akceptuje on --no-verify by ominąć haki.

Answer 4

Seems to be a bug in Git 1.7

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

Zasadniczo powinno działać, jeśli zrobić

git diff 

po rozwiązaniu swoich konfliktów i następnie

git rebase --continue 

powinno działać.

Answer 5

Dzieje się tak, ponieważ podczas rozwiązywania konfliktu usunąłeś cały kod z łaty, która została zastosowana do gałęzi, na którą się opierasz. Użyj numeru git rebase --skip, aby kontynuować.

trochę więcej szczegółów:

Normalnie, przy ustalaniu konflikt podczas podścielanie, będzie edytować konflikt pliku, zachowując część lub cały kod w patch obecnie stosowanej do oddziału ty rebase na . Po zamocowaniu plaster i robi

git add your/conflicted/file 
git status 

dostaniesz (zazwyczaj zielona) linia pokazuje zmodyfikowany plik

modyfikowany: Twój/skonfliktowany/pliku

git rebase --continue będzie dobrze działać w tej sytuacji.

Czasami podczas rozwiązywania konfliktu usuwasz wszystko z nowej łatki, zachowując tylko kod z oddziału, na którym się opierałeś. Teraz, po dodaniu pliku, będzie on dokładnie taki, jak ten, na którym próbowałeś dokonać ponownego wyboru. Status git nie pokazuje zielonej linii wyświetlającej zmodyfikowane pliki. Teraz, jeśli nie

git rebase --continue 

git będzie narzekać z

żadne zmiany - nie można zapomnieć używać 'git add'?

Co git faktycznie chce zrobić w tej sytuacji jest użycie

git rebase --skip 

pominąć poprawkę. Wcześniej nigdy tego nie robiłem, ponieważ zawsze nie byłem pewien, co by mnie omijało, gdybym to zrobił, nie było dla mnie oczywiste, co naprawdę oznacza "pomiń tę poprawkę". Ale jeśli się nie zielona linia z

modyfikowany: Twój/skonfliktowany/plik

po edycji plik skonfliktowany, dodając go i robi git status, to możesz być pewien, że usunięto Cała łatka i możesz zamiast tego używać

git rebase --skip 

, aby kontynuować.

oryginalny post powiedział to czasami działa:

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

... ale nie należy polegać na tym (i pamiętaj, aby nie dodawać pliki resztki w repozytorium folderów)

Answer 6

Po naprawieniu konfliktu upewnij się, że zmienione pliki zostały dodane do plików etapowych. To rozwiązało problem dla mnie.