Git checkout - <файлы> не отбрасывает изменения?

У меня есть изменения в моем рабочем каталоге, который я пытаюсь отбросить (reset к текущей индексированной версии файлов), однако git checkout -- <file> не будет отменять изменения. Я попытался вручную удалить файлы (rm -r files), затем запустил git checkout -- ., который отображает файлы как измененные снова.

$ git checkout -- .
$ 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:   files/Hulk.png
#   modified:   files/Hulk_2.png
#
no changes added to commit (use "git add" and/or "git commit -a")

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

diff --git a/files/Hulk.png b/files/Hulk.png
index 1c256cb..1d37fe0 100644
Binary files a/files/Hulk.png and b/files/Hulk.png differ
diff --git a/files/Hulk_2.png b/files/Hulk_2.png
index 1c256cb..0717199 100644
Binary files a/files/Hulk_2.png and b/files/Hulk_2.png differ

ПРИМЕЧАНИЕ. Некоторые люди сказали запустить git checkout ., однако это приведет к такому же результату, что и git checkout -- .. -- - это всего лишь обозначение, используемое в команде git checkout для различения точек treeish/commit из файлов/путей.

ОС: OSX 10.6 Git: 1.7.10.2

Ответы

Ответ 1

Причина этого связана с несколькими файлами с тем же именем, но с разными случаями. В OSX, который не учитывает регистр, не нравится несколько файлов с тем же именем, но в разных случаях. Он рассматривает их как один и тот же файл. Чтобы исправить это, я запустил git mv (или просто mv) во временное имя файла, добавил временные файлы, что позволило git удалить старые/неправильно названные версии, а затем вторую фиксацию, чтобы назвать их обратно. Это также может быть исправлено в файловой системе, которая позволяет различным файлам с одинаковым именем быть разными.

Ответ 2

Вы пробовали

git config --global core.autocrlf false

или

git config --global core.filemode false

Ответ 3

На основе ваших комментариев вы должны настроить свой репозиторий на чувствительность к регистру:

git config core.ignorecase false

Это позволяет git отслеживать оба файла (хотя в файловой системе отображается только один, что очень запутывает). Ниже приведены шаги репликации, чтобы продемонстрировать, что происходит, когда git правильно отслеживает чувствительность к регистру:

git init /tmp/test && cd /tmp/test
git config core.ignorecase false
echo test>test && git add test && git commit -m "lowercase t"
mv test Test

Теперь git status не показывает отличий от test:

git status -s
 ?? Test

Зафиксируйте test и используйте git ls-files, чтобы увидеть, что мы сейчас отслеживаем:

git add Test && git commit -m "uppercase T"
git ls-files
 Test
 test

Что сообщает ls? Почему, просто "Тест", естественно:

ls
 Test

Наконец, что происходит, когда мы модифицируем Test?

echo garbage>Test
git status -s
 M Test
 M test

Какой беспорядок.

Ответ 4

Используйте. вместо -

git checkout .

Ответ 5

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

Ответ 6

Если вы хотите отменить все сделанные вами изменения, просто используйте

git checkout .

Ответ 7

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

1- используйте другой клон, чтобы изменить строку, заканчивающуюся на UNIX 2 - сдуйте клон, где возникла проблема, и повторите его.

Ответ 8

Я использовал git checkout -.

Также git checkout.

== То же самое, что и op оба работали с Mac OSX 10.7 и Linux, работали на обоих

с git версией 1.7.7.5 (Apple Git -26) а также git 1.7.1 скомпилировано

Попробуйте другое репо и посмотрите, получаете ли вы те же результаты. Может быть, ошибка команды в версии git?

Ответ 9

когда вы удаляете файл из файловой системы с помощью "rm -r файла", вы не удаляете его из репозитория. Yo нужно сделать то же самое в git, используя "git rm"