Git время от времени проглатывает файл

Question

У меня периодически возникают проблемы с моими Git-репозиториями. Я занимаюсь разработкой в ​​Windows, и мой производственный сайт работает под Linux. Несколько раз случалось так, что git показывал все файлы, отслеженные как измененные. Я думал, что это из-за проблемы с конфликтом или конфликта между Windows и Linux, но сегодня утром, когда я проверял репозиторий Linux, он показывал все файлы как измененные.

Чтобы добавить оскорбление к травме, два репозитория Linux, которые я использую (1 для Prod, 1 для теста), показывали одинаково. У меня не было другого выбора, кроме как зафиксировать все файлы, так как полный сброс или извлечение не делали никаких изменений в рабочем каталоге (да, я в значительной степени отстой). Это результат коммита:

Created commit #######: Git, you are so mean...
1521 files changed, 302856 insertions(+), 302856 deletions(-)

Какие-нибудь идеи о том, как разобраться с этим в следующий раз, когда это произойдет?

Answer 1

Как говорит Бомбе, это звучит как проблема с окончанием строки. Самое простое обсуждение этого, которое я видел, это это руководство на Github.

Вы хотите установить core.autocrlf в своей системе Windows, чтобы Git автоматически изменял окончание строк на CRLF при извлечении из репо в рабочий каталог и, наоборот, изменял все CRLF на LF при фиксации файлов в репо:

$ git config --global core.autocrlf true

Затем вы можете убедиться, что в вашем репо есть согласованные окончания строк, либо клонировав из вашего репозитория Linux, либо git reset, который проверяет свежую рабочую копию, которая применяет новый параметр autocrlf ко всем LF:

$ git reset --hard HEAD

EDIT - если Git не распознает файл как двоичный файл, autocrlf может повредить файл, изменив то, что он считает CRLF или LF. Если репозиторий включает необычные типы файлов в двоичном формате, объявите их тип преобразования явно в .gitattributes, как описано в manpage .

Answer 2

Звучит как проблема с окончанием строки. Проверьте man git-config для core.autocrlf.

Answer 3

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

Традиционное значение по умолчанию - git вообще не изменяет содержимое файла на git add в хранилище. Более поздние установщики Windows git включают core.autocrlf, что переводит unix в окончания строк Windows при оформлении заказа, и наоборот при добавлении в хранилище.

По этой причине, если у вас больше ожидаемых изменений, которые вы ожидаете, часто рекомендуется git add все ожидающие файлы (например, через git add -u).

На этом этапе будут применяться любые фильтры очистки / удаления пятен, и git diff --cached должен давать разумную разницу.

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

Для этого вы можете использовать такой инструмент, как hexdump.

Предположим, что myfile.txt имеет различия, которые не видны, вы можете попробовать что-то вроде этого.

# Extract raw versions of the differing files and hexdump to some temporary files
git cat-file blob :myfile.txt | hexdump -C >myfile-stagetmp.bytes
git cat-file blob HEAD:myfile.txt | hexdump -C >myfile-headtmp.bytes

# Diff them. (Yes, you don't have to use git diff!)
git diff --no-index myfile-stagetmp.bytes myfile-headtmp.bytes