Rzuciłem okiem na wszystkie podobne pytania. Jednak dwukrotnie sprawdziłem i zdecydowanie dzieje się coś dziwnego.

Na jednym serwerze (Solaris z Git 1.8.1) sklonowałem repozytorium Git, a następnie skopiowałem folder .git do moich istniejących plików live. To działało idealnie, mogłem biegać

git status

następnie

git diff [filename]

aby sprawdzić inne pliki.

Na innym serwerze (Solaris z Git 1.7.6) robię jednak dokładnie to samo

git diff [filename]

nic nie pokazuje, nawet jeśli zawartość pliku jest zdecydowanie inna. Testowałem też dodawanie nowego pliku, zatwierdzanie go, a następnie edycję. Ten sam problem git statuspokazuje plik jako zmieniony, ale git diffnic nie pokazuje. Jeśli pobieram zmieniony plik i lokalnie uruchamiam diff, otrzymuję dane wyjściowe diff.

Dodałem plik do indeksu :

git add file_name

a następnie uruchomiłem:

git diff --cached file_name

Możesz zobaczyć opis git diff tutaj .

Jeśli chcesz cofnąć dodawanie git, zobacz tutaj: Jak cofnąć „git add” przed zatwierdzeniem?

Istnieje kilka powodów, dla których git statusmoże się to różnić, ale git diffnie.

• Zmienił się tryb (bity uprawnień) pliku - na przykład z 777 na 700.

• Zmieniono styl wysuwu wiersza z CRLF (DOS) na LF (UNIX)

Najłatwiejszym sposobem sprawdzenia, co się stało, jest uruchomienie git format-patch HEAD^i sprawdzenie, co mówi wygenerowana łatka.

Dla mnie miało to coś wspólnego z uprawnieniami do plików. Ktoś z systemem Mac / Linux w moim projekcie wydaje się zatwierdzać niektóre pliki z uprawnieniami innymi niż domyślne, których mój klient git systemu Windows nie mógł odtworzyć. Rozwiązaniem dla mnie było powiedzenie gitowi ignorowania uprawnień do plików:

git config core.fileMode false

Inne spostrzeżenia: Jak sprawić, by Git ignorował zmiany trybu plików (chmod)?

Miałem problem polegający na tym, że setki zakończeń linii zostały zmodyfikowane przez jakiś program i git diffwymieniono wszystkie pliki źródłowe jako zmienione. Po naprawieniu zakończeń linii,git status nadal wyświetlał pliki jako zmodyfikowane.

Udało mi się rozwiązać ten problem, dodając wszystkie pliki do indeksu, a następnie resetując indeks.

git add -A
git reset

core.filemode został ustawiony na false.

Podejrzewam, że coś jest nie tak z instalacją Gita lub repozytorium.

Spróbuj biegać:

GIT_TRACE=2 git <command>

Zobacz, czy znajdziesz coś przydatnego. Jeśli to nie pomoże, po prostu użyj strace i zobacz, co się dzieje:

strace git <command>

Miałem podobny problem: git diffpokazywałbym różnice, ale git diff <filename>nie. Okazało się, że ustawiłem LESSna ciąg zawierający -F( --quit-if-one-screen). Usunięcie tej flagi rozwiązało problem.

Jak już wspomniano w poprzedniej odpowiedzi , sytuacja ta może wynikać z problemów z zakończeniem linii (CR / LF vs. LF). Rozwiązałem ten problem (pod Git w wersji 2.22.0) za pomocą tego polecenia:

git add --renormalize .

Zgodnie z instrukcją:

       --renormalize
           Apply the "clean" process freshly to all tracked files to
           forcibly add them again to the index. This is useful after
           changing core.autocrlf configuration or the text attribute in
           order to correct files added with wrong CRLF/LF line endings.
           This option implies -u.

Krótka odpowiedź

Bieganie git add czasami pomaga.

Przykład

Status Git pokazuje zmienione pliki, a git diff nic nie pokazuje ...

> 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:   package.json

no changes added to commit (use "git add" and/or "git commit -a")
> git diff
> 

... uruchomienie git add rozwiązuje tę niespójność.

> git add
> git status
On branch master
nothing to commit, working directory clean
> 

Natknąłem się na ten problem. Moja sprawa była podobna do tej LESSkwestii pisał przez rcwxok .

W moim przypadku ustawiłem PAGERzmienną środowiskową naPAGER='less -RSF' .

Jednak w przeciwieństwie do poprzednich odpowiedzi, nie chciałem usuwać tej -Fopcji, ponieważ wyraźnie ją tam umieściłem, mając nadzieję, że nie pokaże różnicy wless jeśli jest krótsza niż ekranowa.

Aby uzyskać pożądany efekt, zamiast usuwania -F, dodałem -X: PAGER='less -RSFX'. To zarówno rozwiązało git diffproblem, jak i dodatkowo zapobiega wyświetlaniu krótkich różnic z less.

Właśnie uruchomiłem podobny problem. git diff filenic nie pokazało, ponieważ dodałem plik do indeksu Gita z częścią jego nazwy wielkimi literami:GeoJSONContainer.js .

Potem zmieniłem nazwę na GeoJsonContainer.jsi zmiany przestały być śledzone. git diff GeoJsonContainer.jsnic nie pokazywał. Musiałem usunąć plik z indeksu za pomocą flagi siły i dodać plik ponownie:

git rm -f GeoJSONContainer.js
git add GeoJSONContainer.js

Tak naprawdę nie zadałeś prawdziwego pytania, ale ponieważ jest to ogólny przypadek użycia, którego używam dość często, oto co robię. Możesz spróbować samemu i sprawdzić, czy błąd nadal występuje.

Moje założenie dotyczące twojego przypadku użycia:

Masz istniejący katalog zawierający pliki i katalogi, a teraz chcesz go przekonwertować na repozytorium Git, które jest sklonowane z innego miejsca bez zmiany jakichkolwiek danych w twoim bieżącym katalogu.

Są naprawdę dwa sposoby.

Clone repo - mv .git- git reset --hard

Ta metoda jest tym, co zrobiłeś - aby sklonować istniejące repozytorium do pustego katalogu, a następnie przenieść .gitkatalog do katalogu docelowego. Aby działać bez problemów, zwykle wymaga to uruchomienia

git reset --hard

Jednak zmieniłoby to stan plików w bieżącym katalogu. Możesz wypróbować to na pełnej kopii / rsync swojego katalogu i przestudiować, jakie zmiany. Przynajmniej później nie powinieneś już widzieć rozbieżności między git loga status.

Zainicjuj nowe repozytorium - wskaż początek

Drugi jest mniej niepokojący: dotrzyj cddo celu i rozpocznij nowe repozytorium z

git init

Następnie mówisz temu nowemu repozytorium, że ma przodka w innym miejscu:

git remote add origin original_git_repo_path

Wtedy bezpiecznie

git fetch origin master

kopiować dane bez zmiany plików lokalnych. Teraz wszystko powinno być dobrze.

Zawsze zalecam drugi sposób, aby być mniej podatnym na błędy.

Ponownie natknąłem się na ten problem. Ale tym razem stało się to z innego powodu. Skopiowałem pliki do repozytorium, aby nadpisać poprzednie wersje. Teraz widzę, że pliki są zmodyfikowane, ale diff nie zwraca różnic.

Na przykład mam plik mainpage.xaml. W Eksploratorze plików wkleiłem nowy plik mainpage.xaml na ten w moim obecnym repozytorium. Wykonałem pracę na innym komputerze i właśnie wkleiłem plik tutaj.

Plik pokazuje zmodyfikowane, ale kiedy uruchomię git diff, nie pokaże zmian. Dzieje się tak prawdopodobnie dlatego, że informacje o pliku w pliku uległy zmianie i git wie, że tak naprawdę nie jest to ten sam plik. Ciekawy.

Możesz zobaczyć, że kiedy uruchamiam diff na pliku, nic nie pokazuje, po prostu zwraca znak zachęty.

Miałem ten sam problem opisany w następujący sposób: Jeśli wpisałem

$ git diff

Git po prostu powrócił do monitu bez żadnego błędu.

Jeśli wpisałem

$ git diff <filename>

Git po prostu powrócił do monitu bez żadnego błędu.

W końcu, czytając wokół, zauważyłem, że git difffaktycznie wywołujemingw64\bin\diff.exe do wykonania pracy.

Oto oferta. Używam systemu Windows i zainstalowałem inne narzędzie Bash i zmieniło moją ścieżkę, więc nie wskazuje już na mój mingw64 \ bin .

Więc jeśli wpiszesz:

git diff

i po prostu powraca do monitu, że możesz mieć ten problem.

Rzeczywisty plik diff.exe, który jest uruchamiany, gitznajduje się w katalogu mingw64 \ bin

Wreszcie, aby to naprawić, skopiowałem plik mingw64\bin katalog do lokalizacji, w której szukał go Git. Próbowałem i nadal nie działało.

Następnie zamknąłem okno Git Bash i otworzyłem je ponownie, przeszedłem do tego samego repozytorium, które ulegało awarii i teraz działa.