Я думаю, что было бы полезно дать подсказку о том, как воспроизвести проблему , чтобы лучше понять проблему:
$ git init
$ echo "*.txt -text" > .gitattributes
$ echo -e "hello\r\nworld" > 1.txt
$ git add 1.txt
$ git commit -m "committed as binary"
$ echo "*.txt text" > .gitattributes
$ echo "change.." >> 1.txt
# Ok let's revert now
$ git checkout -- 1.txt
$ git status
modified: 1.txt
# Oooops, it didn't revert!!
# hm let's diff:
$ git diff
warning: CRLF will be replaced by LF in 1.txt.
The file will have its original line endings in your working
directory.
diff --git a/1.txt b/1.txt
index c78c505..94954ab 100644
--- a/1.txt
+++ b/1.txt
@@ -1,2 +1,2 @@
-hello
+hello
world
# No actual changes. Ahh, let's change the line endings...
$ file 1.txt
1.txt: ASCII text, with CRLF line terminators
$ dos2unix 1.txt
dos2unix: converting file 1.txt to Unix format ...
$ git diff
git diff 1.txt
diff --git a/1.txt b/1.txt
index c78c505..94954ab 100644
--- a/1.txt
+++ b/1.txt
@@ -1,2 +1,2 @@
-hello
+hello
world
# No, it didn't work, file is still considered modified.
# Let's try to revert for once more:
$ git checkout -- 1.txt
$ git status
modified: 1.txt
# Nothing. Let's use a magic command that prints wrongly committed files.
$ git grep -I --files-with-matches --perl-regexp '\r' HEAD
HEAD:1.txt
2-й способ воспроизведения: В приведенном выше сценарии замените эту строку:
echo "*.txt -text" > .gitattributes
на
git config core.autocrlf=false
и оставьте остальные строки как
Что говорят все вышеперечисленные? Текстовый файл может (при некоторых обстоятельствах) быть передан с помощью CRLF (например, -text в .gitattributes / или core.autocrlf=false).
Когда позже мы захотим обработать тот же файл как текст (-text -> text), его нужно будет зафиксировать снова.
Конечно, вы можете временно восстановить его (как правильно ответил Абу Ассар ).В нашем случае:
echo "*.txt -text" > .gitattributes
git checkout -- 1.txt
echo "*.txt text" > .gitattributes
Ответ : вы действительно хотите это сделать, потому что это будет вызывать одну и ту же проблему каждый раз, когда вы изменяете файл.
Для записи:
Чтобы проверить, какие файлы могут вызвать эту проблему в вашем репо, выполните следующую команду (git должен быть скомпилирован с --with-libpcre):
git grep -I --files-with-matches --perl-regexp '\r' HEAD
Зафиксировав файл (ы) (предположим, что вы хотите рассматривать их как текст), это то же самое, что сделать то, что предлагается в этой ссылке http://help.github.com/line-endings/ для исправления таких проблем.Но вместо того, чтобы удалить .git/index и выполнить reset, вы можете просто изменить файл (ы), затем выполнить git checkout -- xyz zyf и затем зафиксировать.