Nie można odrzucić zmian w Git

Po zobaczeniu z wiersza poleceń:

# On branch RB_3.0.10
# 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:   index.htm

Próbuję odrzucić zmiany, wpisując polecenie:

git checkout -- index.htm

ale kiedy ponownie uruchomię status git, wygląda to dokładnie tak samo. Kasa nie działa. czy robię coś źle? Używam GIT 1.6.1.2 w systemie Windows / Cygwin.

# On branch RB_3.0.10
# 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:   index.htm

Dręczyło mnie to od jakiegoś czasu, prawie każde repozytorium, które sprawdzałem, zawierało zmiany, których nie mogłem odrzucić. Krótko mówiąc, próbowałem wszystkich powyższych rozwiązań, ale nic nie działało. Oto, co zrobiłem, aby przywrócić normalne działanie (na komputerze Mac):

Completely remove the autocrlf & safecrlf settings from ~/.gitconfig
Completely remove the autocrlf & safecrlf settings from your repo's local config ./.git/config
git rm --cached -r .
git reset --hard

Oto moje doświadczenie, ustaw następujące zmienne w .git/config:

[core]
    autocrlf = false
    safecrlf = false
    eol = crlf

następnie uruchom $ git checkout HEAD .i działa. ale $ git checkout -- .nie, dziwne!

* git w wersji 1.9.3

Jakie zmiany są git diffwidoczne w pliku? W systemie Windows widziałem problemy z zakończeniami linii powodujące takie problemy. W takim przypadku spójrz, jakie masz ustawienia git config core.autocrlfi git config core.safecrlf. Istnieje dokumentacja dotycząca tych ustawień .

Powiedziałbym, że jeśli używasz git svndo integracji z Subversion, upewnij się, że autocrlfjest wyłączony. Z tego, co mogę powiedzieć, jest po prostu zepsuty w tej konfiguracji i sprawia, że ​​większość narzędzi uważa, że ​​pliki zostały zmienione, gdy wykonałeś a, checkoutaby cofnąć wszelkie zmiany.

Jeśli widzisz problem w miejscu, w którym to robisz git checkout, a następnie git statuspokazuje, że plik jest nadal zmodyfikowany i git diffpokazuje, że plik jest zmodyfikowany w każdym wierszu pliku, to jest to problem, który widzisz.

core.autocrlf

Jeśli prawda, powoduje, że git konwertuje CRLF na końcu linii w plikach tekstowych do LF podczas odczytu z systemu plików i konwertuje odwrotnie podczas zapisu do systemu plików. Zmienną można ustawić na wejście, w którym to przypadku konwersja ma miejsce tylko podczas odczytu z systemu plików, ale pliki są zapisywane z LF na końcu linii. Obecnie, które ścieżki traktować jako „tekst” (czyli podlegać mechanizmowi autocrlf), jest ustalane wyłącznie na podstawie treści.

core.safecrlf

Jeśli prawda, sprawia, że ​​git sprawdza, czy konwersja CRLF kontrolowana przez core.autocrlf jest odwracalna. Git sprawdzi, czy polecenie bezpośrednio czy pośrednio modyfikuje plik w drzewie roboczym. Na przykład zatwierdzenie pliku, a następnie wyewidencjonowanie tego samego pliku powinno dać oryginalny plik w drzewie roboczym. Jeśli tak nie jest w przypadku aktualnego ustawienia core.autocrlf, git odrzuci plik. Zmienną można ustawić na „ostrzeżenie”, w którym to przypadku git będzie ostrzegać tylko o nieodwracalnej konwersji, ale będzie kontynuować operację. ...

Myślę, że musisz zdać -f

Ze strony podręcznika ( man git-checkout, GIT-CHECKOUT (1)):

-f, --force
Kontynuuj, nawet jeśli indeks lub drzewo robocze różni się od HEAD.
Służy do odrzucania lokalnych zmian .

Na przykład odrzuć zmiany w bieżącej gałęzi i przełącz się na inną:

git checkout -f master

Mogą to być zakończenia linii, jak sugeruje @ 1800-information, ale inną możliwością jest to, że różnica (która uniemożliwia przywrócenie tych plików za pomocą polecenia wypisania) polega na trybie pliku. To właśnie mi się przytrafiło. W mojej wersji gita możesz to odkryć za pomocą

git diff index.htm

I pokaże ci zmiany trybu plików. Jednak nadal nie pozwala ci ich cofnąć, używając kasy, nawet z opcją -f. Do tego użyj też

git config core.filemode false

lub zmień git .config w edytorze tekstu, dodając

[rdzeń]

filemode = false

Po wykonaniu tej czynności możesz użyć

git reset HEAD index.htm

i plik powinien zniknąć.

(Wszystko to otrzymałem z odpowiedzi na Jak zrobić zmiany trybu ignorowania git (chmod)? I aktualizowanie-pliku-uprawnienia-tylko-w-git )

Czy korzystasz z OSX czy Windows? Jeśli tak, prawdopodobnie problem polega na tym, że istnieją dwa pliki o tej samej nazwie, z różnymi wielkościami. na przykład. index.htm i Index.htm

Windows i domyślnie OSX używają systemu plików bez rozróżniania wielkości liter, co powoduje konflikt z git z rozróżnianiem wielkości liter.

Miałem ten problem i po wypróbowaniu wszystkich powyższych nic nie działało.

Udało mi się usunąć katalog, w którym znajdował się plik, a następnie git statuszrobić i upewnić się, że wszystkie pliki w tym katalogu są teraz oznaczone jako usunięte. Potem po prostu to zrobiłem git checkout -fi wszystko wróciło do normy.

Pracowałem nad libGDXprojektem Android Studioi chciałem odrzucić wszystkie zmiany, które wprowadziłem, i nic mi nie działało, rozwiązanie, które wymyśliłem, polegało na wprowadzeniu wszystkich zmian do nowej gałęzi

git checkout -b TRASH
git add .
git commit -m "discarded changes"
git checkout master

a następnie możesz usunąć TRASHoddział, jeśli chcesz.

Miałem ten sam problem, nic z powyższych komentarzy nie działało. Okazało się, że w moim systemie plików wielkość liter nie jest rozróżniana (domyślnie osx, ale okna prawdopodobnie zachowują się tak samo), a plik z dużymi i małymi literami był obecny w tym samym katalogu, z inną zawartością. Ponieważ na moim komputerze obie nazwy wskazywały na ten sam plik, status git zawsze pokazywał modyfikację, bez względu na to, co zrobiłem. Aby rozwiązać problem:

• Musiałem usunąć jeden z plików z innego komputera i przesłać go do repozytorium

• całkowicie usunąć całą wersję lokalną

• zrobić git clone od zera

Miałem podobny problem, który nie pozwalał mi na odrzucenie plików, które albo nie istnieją, albo zostały zmienione. Używam Visual Studio w pracy i odkryłem, że dzieje się tak podczas przełączania gałęzi, gdy aplikacja jest uruchomiona.

git checkouta próba odrzucenia nie pomogła. To by nie zadziałało lub po prostu powiedziałoby mi, że nie mam pozwolenia.

Rozwiązanie, które zadziałało:

1. Przejdź do trybu awaryjnego
2. Odrzuć pliki

Ponowne uruchamianie jest uciążliwe, ale działało szybciej niż wypróbowanie 100 rzeczy.

Jest proste rozwiązanie. Jeśli tak się stanie (zwykle z powodu nieoczekiwanego zamknięcia systemu Windows lub zrzutu pamięci) i nie możesz odrzucić zmian, a nawet przełączać się między gałęziami (Git mówi, że nie masz wystarczających uprawnień); w Windowsśrodowisku show all hidden files and foldersz opcji folderów. Przejdź do katalogu GIT (powinien zaczynać się od .git) i usuń "index.lock"plik. W takim razie Git powinien pozwolić ci robić wszystko, co chcesz.

Skończyło się na tym, że wykonałem git stasha, git stash cleanaby pozbyć się niektórych. Nie widziałem żadnych konfiguracji auto cr / lf w plikach .git / lub ~ / .git.

W moim przypadku nie mogłem odrzucić zmian związanych z katalogiem. np. kiedy uruchomiłem różnicę git, zobaczyłem to: -Subproject commit fdcccccccccccccccccccccccccccccccccccccc +Subproject commit f1bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

Zadzwoniłem więc do tego katalogu i sprawdziłem w nim status git. To było w stanie odłączonym HEAD. A potem właśnie tam uruchomiłem git checkout master. To wszystko naprawiło dla mnie. Ale to nie jest pomocne w przypadku dokładnego scenariusza, o który tutaj pytano.

To stare pytanie, ale wciąż było dla mnie aktualne. Nie znalazłem odpowiedzi, dopóki nie zapytałem w biurze i odkryłem, że problem dotyczy modułów podrzędnych. Kiedy są aktualizowane, a twoje własne repozytorium nie odzwierciedla tych zmian, pokazuje się, że mają różnice, zresetowanie głowy nie pomaga. W takim przypadku uruchom:

git status update

To powinno pomóc naprawić rzeczy (w tym konkretnym przypadku)

Miałem problem z uprawnieniami w systemie Windows i musiałem to zrobić, icacls containingFolder /reset /t /l /ca następnie dwukrotnie kliknąć folder, aby odzyskać moje uprawnienia.

Miałem .gitattributes z następującą zawartością:

* text=auto eol=lf

Aby rozwiązać ten problem, edytuj, .gitattributesaby usunąć tę linię, która rozluźnia zakończenia linii. Następniegit reset --hard HEAD przywrócono pliki i .gitattributesplik.

Dla mnie ten problem pojawił się z połączeniem pobierania obrazu Git-LFS, który został przesłany przez Netlify CMS i obsługiwany inaczej przez ich obsługę Netlify Large Media.

Moim rozwiązaniem było zakomentowanie / usunięcie tych wierszy z mojego ~/.gitconfig, aby wyglądały jak poniżej, a następnie git statusponowne sprawdzenie .

# [filter "lfs"]
#   clean = git-lfs clean %f
#   smudge = git-lfs smudge %f
#   required = true

LUB prawdopodobnie możesz dodać bardziej lokalny filtr przez a .gitconfigw katalogu głównym repozytorium i w jakiś sposób nadpisać tam reguły filtrowania dla lfs.

Mam nadzieję, że to pomoże komuś.

Miałem też podobny problem i pomogły mi następujące kroki:

git commit -am 'temp commit'
git pull origin master
git reset head~1
git reset head --hard

Mam nadzieję, że pomoże to również innym ludziom.