Подтвердить что ты не робот

Git показывает идентичные файлы, измененные

Git показывает мне, что весь файл изменяется, когда я не могу понять изменения. Это cygwin git, но это также происходит в msysgit

$ git --version
git version 2.1.1

$ diff <(git show HEAD:File.cs) <(cat File.cs)
// Shows no differences

$ diff <(git show HEAD:File.cs | xxd) <(xxd File.cs)
// Shows no differences

$ git diff
// shows the entire file has changed

$ git hash-object <(git show HEAD:File.cs)
7b3762473342a5b040835bfef9f6b45c109ba48b

$ git hash-object <(cat File.cs)
7b3762473342a5b040835bfef9f6b45c109ba48b

$ git hash-object File.cs
7b3762473342a5b040835bfef9f6b45c109ba48b

У меня

$ git config --get core.fileMode
false

и

$ git config --get core.autocrlf
true

Я действительно не знаю, что происходит, все хочет, чтобы они были одинаковыми, но git хочет создать фиксацию, говорящую, что все содержимое было удалено и воссоздано. Кто-нибудь, кто знает, что git сантехника лучше имеет предложение?. Все, что я могу представить, это git show - удаление/нормализация нечетных окончаний строки.

UPDATE:

Я уверен, что это происходит потому, что процесс разработки такой. Оформить заказ от git, rsync до dev машины, разработать, rsync обратно. Я считаю, что rsync возится с концами строк. Это просто странно, что gits не сообщают о концах строк, и кажется, что он действительно запутался в том, что, черт возьми, происходит. Хотя отличие двоичного представления файлов кажется одинаковым.

ОБНОВЛЕНИЕ 2:

Так что это очень раздражает, и я чувствую, что наткнулся на ошибку в git.

Например

$ git gc
$ git checkout -- .
$ git clean -fd
$ git status

> shows a heap of modified files

Я уверен, что не должен показывать никаких изменений, независимо от того, где его запускают, но я получаю список из 20 странных вещей: (

4b9b3361

ОТВЕТЫ

Ответ 1

Это может быть вызвано файлом .gitattributes, указывающим на git, что он должен выполнять нормализацию EOL, но репозиторий, содержащий ненормированные окончания строк.

Простое исправление - удалить соответствующую строку из .gitattributes. Это может быть

* text=auto

или

*.cs text

Быстрый пример того, как это могло произойти, выглядит следующим образом:

$ echo "Hello World" > example.txt
$ unix2dos example.txt #Make sure it uses CRLF
$ git add example.txt
$ git commit -m "commit 1"
$ #Instruct git that all .txt files should be normalized
$ echo '*.txt text' >> .gitattributes 
$ git add .gitattributes
$ git commit -m "commit 2"

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

Однако на данный момент git status не замечает этого, потому что сам файл не изменился по размеру или mtime, поскольку он был добавлен в индекс, поэтому индекс считается актуальным:

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

Но все, что делает недействительным индекс, заставит git считать файл грязным:

$ touch example.txt
On branch master
Changes not staged for commit:

        modified:   example.txt

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

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

Вот почему справочная страница GITATTRIBUTES(1) рекомендует явно аннулировать весь индекс при введении нормализации строки так:

$ echo "* text=auto" >>.gitattributes
$ rm .git/index     # Remove the index to force Git to
$ git reset         # re-scan the working directory
$ git status        # Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"

Подробнее читайте в разделе "Окончательное преобразование строки" на странице gitattributes.

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