git status показывает изменения, git checkout - <file>не удаляет их

Question

Я хочу удалить все изменения в моей рабочей копии.
Запуск git status показывает измененные файлы.
Ничто из того, что я делаю, не удаляет эти модификации.
Например:

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout -- Rhino.Etl.Core/Enumerables/CachingEnumerable.cs

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git checkout `git ls-files -m`

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git reset --hard HEAD
HEAD is now at 6c857e7 boo libraries updated to 2.0.9.2 and rhino.dsl.dll updated.

rbellamy@PROMETHEUS /d/Development/rhino-etl (master)
$ git status
# On branch master
# 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:   Rhino.Etl.Core/Enumerables/CachingEnumerable.cs
#       modified:   Rhino.Etl.Core/Pipelines/SingleThreadedPipelineExecuter.cs
#       modified:   Rhino.Etl.Tests/Rhino.Etl.Tests.csproj
#       modified:   Rhino.Etl.Tests/SingleThreadedPipelineExecuterTest.cs
#
no changes added to commit (use "git add" and/or "git commit -a")

Answer 1

У меня была эта проблема в Windows, но я не был готов разобраться в последствиях использования config --global core.autocrlf false Я также не был готов отказаться от других частных веток и вкусностей в моем тайнике и начать с нового клона. Мне просто нужно что-то сделать. Теперь.

Это сработало для меня при мысли, что вы позволите git полностью переписать ваш рабочий каталог:

git rm --cached -r .
git reset --hard

(Обратите внимание, что запуск только git reset --hard не был достаточно хорош, как и не было rm файлов до reset, как это предлагается в комментариях к исходному вопросу)

Answer 2

Есть несколько проблем, которые могут вызвать это поведение:

Нормализация окончания строки

У меня тоже были такие проблемы. Все сводится к тому, что git автоматически конвертирует crlf в lf. Обычно это вызвано смешанным окончанием строки в одном файле. Файл нормализуется в индексе, но когда git затем снова денормализует его, чтобы сравнить его с файлом в рабочем дереве, результат будет другим.

Но если вы хотите это исправить, вы должны отключить core.autocrlf , изменить все окончания строки на lf, а затем включить его снова. Или вы можете отключить его, выполнив:

git config --global core.autocrlf false

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

Также рассмотрите возможность установки core.safecrlf для предупреждения, если вы хотите, чтобы git предупреждал вас, когда будет выполнена необратимая нормализация.

git manpages произнесите это:

Конверсия CRLF имеет небольшой шанс порчи данных. autocrlf = true будет конвертировать CRLF в LF во время коммита и LF в CRLF во время оформления заказа. Файл который содержит смесь LF и CRLF до того, как коммит не может быть воссоздан по мерзавцу Для текстовых файлов это что нужно сделать: исправляет строку окончания такие, что у нас есть только НЧ линия окончания в хранилище. Но для бинарные файлы, которые случайно классифицируется как текст, конвертация может поврежденные данные.

Нечувствительные к регистру файловые системы

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

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

Answer 3

Другое решение, которое может работать для людей, так как ни один из вариантов текста не работал для меня:

1. Заменить содержимое .gitattributes одной строкой: * binary. Это говорит git обрабатывать каждый файл как двоичный файл, с которым он ничего не может сделать.
2. Проверьте, что сообщение об испорченных файлах пропало; если это не так, вы можете git checkout -- <files> восстановить их до версии хранилища
3. git checkout -- .gitattributes для восстановления файла .gitattributes в исходное состояние
4. Убедитесь, что файлы по-прежнему не помечены как измененные.

Answer 4

Для будущих людей, имеющих эту проблему: Изменения файлового режима также могут иметь те же симптомы. git config core.filemode false это исправит.

Answer 5

Это сводило меня с ума, тем более, что я не мог исправить это без каких-либо решений, найденных в Интернете. Вот как я это решил. Не могу взять кредиты здесь, так как это работа коллеги:)

Источник проблемы: моя первоначальная установка git была без автоматического преобразования строки в windows. Это привело к тому, что мой первоначальный коммит в GLFW не имел правильного окончания строки.

Примечание. Это только локальное решение. Следующий парень, клонирующий репо все еще застрянет с этой проблемой. Постоянное решение может быть нашел здесь: https://help.github.com/articles/dealing-with-line-endings/#re-normalizing-a-repository.

Настройка: Xubuntu 12.04 Git-репо с проектом glfw

Проблема: невозможно сбросить файлы glfw. Они всегда отображаются как измененные, независимо от того, что я пытался.

Решено:

edit .gitattributes

Comment out the line:    # text=auto

Save the file

restore .gitattributes:   git checkout .gitattributes

Answer 6

У меня был файл .bat с той же проблемой (не удалось избавиться от него в неотслеживаемых файлах). git checkout - не сработало, и на этой странице не было ни одного предложения. Единственное, что сработало для меня, это сделать:

git stash save --keep-index

А затем удалить тайник:

git stash drop

Answer 7

Получил один и тот же вопрос дважды! Оба раза, когда спрятали некоторые изменения, я сделал, а затем попытался вернуть их обратно. Невозможно выдвинуть изменения, так как у меня есть много файлов, которые были изменены, но это не так! Они точно такие же.

Теперь я думаю, что попробовал все вышеперечисленные решения без успеха. После попытки

git rm --cached -r .
git reset --hard

Теперь я изменил почти все файлы в моем хранилище.

При проверке файла говорится, что я удалил все строки, а затем добавил их снова.

Вид беспокойства. Теперь я не буду прятаться в будущем.

Единственное решение - клонировать новый репозиторий и начать заново. (Сделал это в прошлый раз)

Answer 8

Мне удалось исправить это только путем временного удаления файла репозитория .gitattributes моего репо (который определил * text=auto и *.c text).

Я запустил git status после удаления, и изменения исчезли. Они не вернулись даже после того, как .gitattributes был возвращен на место.

Answer 9

Попробуйте выполнить

git checkout -f

Это должно очистить все изменения в текущем рабочем локальном репо

Answer 10

У меня были такие же симптомы, но были вызваны другой причиной.

Я не смог:

git checkout app.js //did nothing
git rm app.js //did nothing
rm -rf app.js //did nothing

даже на git rm --cached app.js он подписывается как удаленный, а в неотслеживаемых файлах я видел app.js. Но когда я снова попробовал rm -rf app.js и peform git status, он все равно показывает мне файл в «неотслеживаемом» состоянии.

После пары попыток с коллегой мы узнали, что это было вызвано Grunt!

Поскольку Grunt был включен, и поскольку app.js был сгенерирован из пары других js-файлов, мы обнаружили, что после каждой операции с js-файлами (также это app.js) grunt снова создает заново app.js .