Git nie przywróci ani nie zatwierdzi pliku, który według niego jest zmodyfikowany.

Question

Przekonwertowałem repozytorium SVN na Git, wykonując następujące czynności: this tutorial. A teraz nie można wydobyć sub-repozytorium, jak sugerowano w this answer.

Przebij długi post, ale większość tekstu to ładnie sformatowane wyjście git.

OS: Windows 8 linia Command: MinGW wersji Git: 1.8.1.msysgit.1

Proces wydobywania subrepository nie wydają się działać, chyba że masz czyste miejsce postoju i nie modyfikowana akta.

git status mówi, że mam zmodyfikowany plik, mimo że jest to nowy import SVN. Ok, spróbujmy się go pozbyć.

Spróbuj i przywróć plik.

user$ git status 
# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: folder with space/folder/toolbar.png 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

user$ git checkout -- "folder with space/folder/toolbar.png" 

user$ git status 
# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: folder with space/folder/toolbar.png 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

To nie działało, ale nie obchodzi mnie, czy to zrobię, więc spróbuję to jeszcze raz.

user$ git commit -a -m "Testing if committing fixes it" 
# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: folder with space/folder/toolbar.png 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

user$ git status 
# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: folder with space/folder/toolbar.png 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

Zatwierdzanie przez pomijanie etapów nie działa, więc spróbujmy je najpierw przygotować.

user$ git add "folder with space/folder/toolbar.png" 

user$ git status 
# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  modified: folder with space/folder/toolbar.png 
# 
no changes added to commit (use "git add" and/or "git commit -a") 

Nie działa, więc jestem zaskoczony ... Idź i spytaj kogoś mądrzejszego.

Jestem nowy dla git ale dobrze wiem z Hg i czytałem this online tutorial, aby zacząć.

Jest całkowicie możliwe, że zawiodłem prosty rozkaz.

Już próbowałem: Rozejrzałem się na rozwiązanie mojego konkretnego problemu, ale miał trochę szczęścia. Natknąłem się na this answer, który wydaje się być powiązany, ale nie do końca rozwiązuje mój problem.

Edytuj: Rzeczy, które mogą być interesujące To część mnie dezorientuje. Przekazałem to repozytorium jakiś czas temu do internetowego repozytorium. Po świeżym klonie repozytorium nadal uważa, że ​​plik jest zmodyfikowany (tj. git status zwraca ten sam wynik, a ja już ustawiłem git config --global core.autocrlf false i zweryfikowałem, uruchamiając git config --global core.autocrlf, który rzeczywiście zwraca wartość false).

Edit 2: FIX znaleźć, ale problem nadal nie jest rozumiane udało mi się naprawić repozytorium po prostu przez usunięcie pliku z systemu, obszar przemieszczania i następnie popełnienia zmiany. Po tym, aby odzyskać plik, po prostu skopiowałem go i przekazałem do repozytorium.

Problem, choć poprawiony, tylko bardziej mnie zdezorientował.

Podczas zabawy z usunięciem pliku zauważyłem, że jeśli zresetuję repozytorium do HEAD, którego ostatnie zatwierdzenie usunęło plik, status git będzie wskazywał, że nic się nie zmieniło i że plik nie jest śledzony, ale plik zostanie odtworzony w w moim roboczym drzewie. To dziwne, biorąc pod uwagę, że jest oznaczony jako usunięty w git ...

Dopiero po usunięciu go po raz drugi, mimo że git już go nie pamięta, udało mi się go usunąć, aby git reset i git reset --hard nie przywróciły pliku.

Jeśli ktoś mógłby mi wyjaśnić, w jaki sposób znalazłem się w tym stanie i jeśli jest to błąd w git lub normalnym zachowaniu, byłbym bardzo wdzięczny.

Moi suspitions Straciłem sekwencję poleceń, które użyłem, ale co się stało poszedł coś takiego: plik jest Images/toolbar.png, a ja nawigować do folderu Images.

Po Usunąłem go z git systemu plików wykryte zmiany tak:

# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
#  deleted: toolbar.png 
#  deleted: ../images/toolbar.png 
# 

uwagę na fakt, że folder images nie są aktywowane! Jest uruchamiany w systemie Windows, który ignoruje przypadek ścieżki. Podejrzewam, że to może być część problemu ...

Jestem naprawdę zdezorientowany, ale mój problem zniknął. Tak więc ten post pozostaje tylko ciekawostką, chociaż nie mogę odtworzyć zachowania, które zachowuje w konwersji z SVN.

Answer 1

Miałem podobny problem jakiś czas temu.

Czy wielkość liter w tym pliku lub katalogu, w którym się on zmieniał w jakimkolwiek momencie?

Miałem katalog z wielką literą, który został zmieniony na wszystkie małe litery (powiedzmy, że przeszedł od /Foo do /foo). Dał mi te same problemy, które opisałeś.

Ilekroć zmodyfikowany plik, to dał mi moc podobną do tej:

#  modified: bar.txt 
#  modified: ../Foo/bar.txt 

miałem również ten sam problem gdzie popełnienie lub resetowanie nie produkował żadnych wyników.

Myślę, że przyczyną problemu jest to, że ścieżki plików systemu Windows nie rozróżniają wielkości liter, ale są to uniksowe. Ponieważ wiele z tych narzędzi wiersza polecenia, takich jak Git, jest opracowywanych na systemach Unix-y, czasami nie radzą sobie z tą różnicą i mogą się mylić, gdy plik zostanie dodany jako Foo/bar.txt i foo/bar.txt. Myślę, że to sprawia, że ​​Git sądzi, że istnieją dwa różne pliki, w których jest tylko jeden.

Moja ostateczna poprawka była taka sama jak Twoja, usuń cały katalog z historii, a następnie dodaj go ponownie (i nigdy więcej nie zmieniaj wielkości liter). To również spowodowało tę samą dziwaczność, którą opisałeś, kiedy musiałem ją usunąć dwa razy, zanim ją zabrałem.

W każdym razie wiem, że to nie jest ostateczna odpowiedź, ale od tego czasu udało mi się odtworzyć problem, więc jestem prawie pewien, że to spowodowało (przynajmniej dla mnie).

Answer 2

Miałem podobny problem spowodowany posiadaniem dwóch plików o tej samej nazwie, co mój komputer.

Wiadomość stawała się:

# On branch master 
# Changes not staged for commit: 
# (use "git add <file>..." to update what will be committed) 
# (use "git checkout -- <file>..." to discard changes in working directory) 
# 
# modified: images/contact_seller.GIF 
# 

Stało się to dlatego, że transakcje repo początkowej commit została wykonana z MacBooka, który jest sformatowany wielkość liter, a błąd był pojawiający się na moim iMac, który został sformatowany wielkości liter.

na maszynie wielkość liter można zobaczyć dwa pliki

SwedishChef$ ls images/contact_seller* 
images/contact_seller.GIF images/contact_seller.gif 

co nie jest ważne na drugiej maszynie więc git musiała coś z tym zrobić.

Po prostu musiałem zmienić nazwę pliku i zatwierdzić te zmiany.