Ответ 1

Я добавил файл в index:

git add file_name

а затем выполните:

git diff --cached file_name

Здесь вы можете увидеть описание git diff .

Если вам нужно отменить добавление git, см. здесь: Как отменить 'git добавить' перед фиксацией?

Ответ 2

Есть несколько причин, по которым git status может показать разницу, но git diff может не быть.

• Изменен режим (бит разрешения) файла - например, от 777 до 700.

• Стиль линии перевода изменен с CRLF (DOS) на LF (UNIX)

Самый простой способ узнать, что произошло, - запустить git format-patch HEAD^ и посмотреть, что говорит сгенерированный патч.

Ответ 3

Для меня это имело какое-то отношение к разрешениям файлов. Кто-то с Mac/Linux в моем проекте, похоже, фиксирует некоторые файлы с разрешениями, отличными от параметров по умолчанию, которые мой клиент Windows git не смог воспроизвести. Решение для меня состояло в том, чтобы сообщить git игнорировать права доступа к файлам:

git config core.fileMode false

Другое понимание: Как мне изменить git игнорировать режим файла (chmod)?

Ответ 4

У меня возникла проблема, когда несколько версий строк были изменены некоторыми программами, а git diff перечислял все исходные файлы как измененные. После фиксации окончаний строки статус git по-прежнему перечислял файлы как измененные.

Я смог исправить эту проблему, добавив все файлы в индекс и затем сбросив индекс.

git add -A
git reset

core.filemode установлено значение false.

Ответ 5

Я подозреваю, что что-то не так с вашей установкой git или с вашим репозиторием.

Попробуйте запустить:

GIT_TRACE=2 git <command>

Посмотрите, если вы получите что-нибудь полезное. Если это не поможет, просто спрячься и посмотри, что происходит не так:

strace git <command>

Ответ 6

У меня была аналогичная проблема: git diff будет показывать различия, но git diff <filename> не будет. Оказалось, что я установил LESS в строку, содержащую -F (--quit-if-one-screen). Удаление этого флага решило проблему.

Ответ 7

Перейдем к этой проблеме. Мой случай был похож на вопрос LESS, отправленный @rcwxok.

В моем случае я устанавливаю среду PAGER var в PAGER='less -RSF'.

Однако, в отличие от предыдущих ответов, я не хотел удалять параметр -F, потому что я явно помещаю его туда, надеясь предотвратить показ diff в LESS, если он короче, чем экранный.

Чтобы получить желаемый результат, вместо удаления -F я добавил -X: PAGER='less -RSFX'. Это и решило проблему git diff, и, кроме того, она предотвращает показ коротких разностей с помощью LESS.

Надеюсь, это поможет кому-то.

Ответ 8

Короткий ответ

Иногда работает git add.

Пример

Git статус показывает измененные файлы, а git diff ничего не показывает...

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

... running git add разрешает несогласованность.

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

Ответ 9

Я только что столкнулся с подобной проблемой. git diff file ничего не показал, потому что я добавил файл в индекс git с некоторой частью его имени в верхнем регистре: GeoJSONContainer.js. Впоследствии я переименовал его в GeoJSONContainer.js, и изменения перестали отслеживаться. git diff GeoJsonContainer.js ничего не показывал. Если бы удалить файл из индекса с помощью флага силы и снова добавить файл:

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

Ответ 10

Вы действительно не задавали актуальный вопрос, но поскольку это общий прецедент, я часто использую здесь то, что делаю. Вы можете попробовать это самостоятельно и посмотреть, сохраняется ли ошибка.

Мое предположение о вашем случае использования: У вас есть существующий каталог, содержащий файлы и каталоги, и теперь вы хотите преобразовать его в репозиторий git, который клонируется из какого-либо другого места, без изменения каких-либо данных в вашем текущем каталоге.

Есть два способа.

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

Этот метод - это то, что вы сделали - клонировать существующее репо в пустой каталог, а затем перемещать директорию .git в целевой каталог. Чтобы работать без проблем, обычно для этого требуется запустить

git reset --hard

Однако это изменит состояние файлов в вашем текущем каталоге. Вы можете попробовать это на полной копии /rsync своего каталога и изучить, какие изменения. По крайней мере после этого вы больше не должны видеть расхождения между git log и status.

Инициировать новое репо - указать на начало координат

Второе меньше беспокоит: cd в пункт назначения и запускает новое репо с

git init

Затем вы скажете, что новое репо, что у него есть предок где-то еще:

git remote add origin original_git_repo_path

Затем безопасно

git fetch origin master

для копирования данных без изменения локальных файлов. Теперь все должно быть хорошо.

Я всегда рекомендую второй способ уменьшить вероятность ошибок.

Ответ 11

У меня была такая же проблема, описанная следующим образом: Если я набрал

$ git diff 

git просто возвращается в приглашение без ошибок.

Если я набрал

$ git diff <filename>

git просто возвращается в приглашение без ошибок.

Наконец, прочитав, я заметил, что git diff на самом деле вызывает mingw64\bin\diff.exe для выполнения работы.

Здесь сделка. Я запускаю окна и установил еще одну утилиту bash, и она изменила мой путь, чтобы она больше не указывала на мой каталог mingw64\bin.

Итак, если вы наберете: git diff и он просто возвращается в приглашение, у вас может возникнуть эта проблема.

Фактический файл diff.exe, который запускается git, находится в вашем mingw64\bin Каталог

Наконец, чтобы исправить это, я фактически скопировал каталог mingw64\bin в папку git, который искал его. Я попробовал его, но он все еще не работал.

Затем я закрыл окно git bash и открыл его снова, перешел на то же самое репо, которое не срабатывало, и теперь оно работает.

Надеюсь, это тоже поможет.

Ответ 12

Я снова наткнулся на эту проблему. Но на этот раз это произошло по другой причине. Я скопировал файлы в репо, чтобы перезаписать предыдущие версии. Теперь я вижу, что файлы изменены, но diff не возвращает diff.

Например, у меня есть файл mainpage.xaml. В File Explorer я вставил новый файл mainpage.xaml поверх того, который был в моем текущем репо. Я сделал работу на другой машине и просто вложил файл здесь.

Файл отображается измененным, но когда я запускаю git diff, он не покажет изменения. Вероятно, потому, что fileinfo в файле изменился и git знает, что это не тот же файл. Интересно.

Вы можете видеть, что когда я запускаю diff в файле, он ничего не показывает, просто возвращает приглашение.

Ответ 13

Как уже отмечалось выше, эта ситуация может возникнуть из-за проблем с окончанием строки (CRLF против LF). Я решил эту проблему (в git версии 2.22.0) с помощью этой команды:

git add --renormalize .

Согласно инструкции:

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