Git: nie można cofnąć lokalnych zmian (błąd: ścieżka… nie jest scalona)


336

Mam następujący działający stan drzewa

$ git status foo/bar.txt
# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       deleted by us:      foo/bar.txt
#
no changes added to commit (use "git add" and/or "git commit -a")

Plik już foo/bar.txttam jest i chcę go ponownie przywrócić do „niezmienionego stanu” (podobnie do „svn revert”):

$ git checkout HEAD foo/bar.txt
error: path 'foo/bar.txt' is unmerged
$ git reset HEAD foo/bar.txt
Unstaged changes after reset:
M       foo/bar.txt

Teraz robi się mylące:

$ git status foo/bar.txt
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#       new file:   foo/bar.txt
#
# Changed but not updated:
#   (use "git add <file>..." to update what will be committed)
#   (use "git checkout -- <file>..." to discard changes in working directory)
#
#       modified:   foo/bar.txt
#

Ten sam plik w obu sekcjach, nowy i zmodyfikowany? Co powinienem zrobić?


7
Chciałbym, aby ktoś mógł wyjaśnić, w jaki sposób wchodzimy w tę sytuację, dlaczego tak się dzieje i dlaczego rozwiązanie działa.
Marcos Dione,

1
Znalazłem się w tej sytuacji, kiedy wyskoczyłem z mojego magazynu po rebase, który doprowadził mnie do konfliktu scalania (stash pop dokonuje scalenia) .... Aby rozwiązać ten problem, zrobiłem „kasę - ich” .... najwyraźniej mój zmiany wciąż tam były ... aby je usunąć. Ponownie próbowałem pobrać plik. wtedy zobaczyłem powyższy błąd.
Arindam Roychowdhury,

Odpowiedzi:


555

Zrobiłeś to niewłaściwie. Musisz najpierw zresetować, usunąć scenę z pliku, a następnie wyewidencjonować i przywrócić lokalne zmiany.

Spróbuj tego:

$ git reset foo/bar.txt
$ git checkout foo/bar.txt

Dzięki; działało jak urok! Musiałem zatwierdzić ( nie z argumentem -a, odpowiednie zmiany były już zainscenizowane), a następnie byłem w stanie pchać / ciągnąć jak zwykle.
Patrick

18
Dla mnie wymagało to: <br/> $ git reset - foo / bar.txt <br/> $ git Checkout - foo / bar.txt <br/> (zauważ dodatkowe „-” pomiędzy)
stycznia 2011

4
Dobra składnia to „git reset HEAD file1 file2 ...”, a następnie „git checkout - file1 file2 ...”
Thomas Decaux

1
Zawsze jest zabawnie, gdy najwyżej głosowana odpowiedź w zasadzie mówi „robisz to źle” :)
nathanchere 16.12

4
Wyjaśnienie (co się dzieje) byłoby świetne…
Kissaki,

51

To działało idealnie dla mnie:

$ git reset -- foo/bar.txt
$ git checkout foo/bar.txt

14
git checkout origin/[branch] .
git status

// Uwaga kropka (.) Na końcu. I wszystko będzie dobrze


-2
git checkout foo/bar.txt

próbowałeś tego? (bez słowa kluczowego HEAD)

Zwykle przywracam zmiany w ten sposób.


1
Typowy błąd podczas próby checkoutscalenia: $ git co path/to/file= wynik => error: path 'path/to/file' is unmerged => więc najpierw uruchom:, $ git reset path/to/filea następnie git checkout path/to/filepowinno działać.
Michael

2
Brak określenia HEAD spowoduje, że git Checkout wyewidencjonuje się z indeksu, co jest słabszą operacją (źródłem treści jest raczej indeks niż HEAD). Co więcej, nie sądzę, żeby miało to w ogóle znaczenie w tym przypadku - z konkretnym problemem postawionym w pytaniu. Czy pan spróbować?
Kissaki,

-4

Uważam, że git skrytka jest bardzo przydatna do czasowej obsługi wszystkich „brudnych” stanów.


4
Jeśli uznasz to za przydatne, proszę wyjaśnić, w jaki sposób pomogłoby w tym konkretnym przypadku. Jak byś go tutaj użył?
Kissaki,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.