Я клонировал репозиторий с несогласованными окончаниями строк. Я добавил .gitattributes, который устанавливает текстовый атрибут для файлов, которые я хочу нормализовать. Теперь, когда я фиксирую изменения, я получаю сообщение:
warning: CRLF will be replaced by LF in FILE.
The file will have its original line endings in your working directory.
Как я могу заставить git нормализовать мою рабочую копию файла для меня? Предпочтительно, чтобы git нормализовал все рабочее дерево.
В клиенте Git версии 2.16 и выше сделать это стало намного проще. Просто используйте:
git add --renormalize .
Примечание: лучше делать это с чистой рабочей областью. Подробнее см.:
error: unknown option 'renormalize'
- person Ryan Nghiem; 25.07.2019
git --version? Я предполагаю, что он просто старше 2.16, и вам нужно обновить его. ХТН
- person philippn; 29.07.2019
git status возвращает что-то вроде nothing to commit, working tree clean
- person philippn; 05.07.2020
Для тех, кто использует v2.16 или выше, вы можете просто использовать:
git add --renormalize . # Update index with renormalized files
git status # Show the files that will be normalized
git commit -m "Introduce end-of-line normalization"
Эти указания взяты прямо из gitattributes. Для более старых версий документы (до версии 2.12) предоставляют другой ответ:
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 (с 2.12 по 2.14) представлен новый набор инструкций. (после редактирования файлов .gitattributes):
git read-tree --empty # Clean index, force re-scan of working directory
git add .
git status # Show files that will be normalized
git commit -m "Introduce end-of-line normalization"
Спасибо @vossad01 за указание на это.
Кроме того, при любом решении файлы в вашей рабочей копии по-прежнему сохраняют свои старые окончания строк. Если вы хотите обновить их, убедитесь, что ваше рабочее дерево чистое, и используйте:
git rm --cached -r .
git reset --hard
Теперь окончания строк в вашем рабочем дереве будут правильными.
.gitattributes или изменении настройки, но не работает, если рабочее дерево имеет другой EOL (по крайней мере, с MsysGit это не так). Для этого кажется, что git rm --cached -r ., а затем git reset --hard сработали (предупреждение: разрушает ваше рабочее дерево). Из help.github.com/articles/dealing-with-line-endings.
- person waddlesplash; 15.02.2014
git add . после удаления индекса (не забывая обо всем в рабочем каталоге, которое ранее не отслеживалось).
- person vossad01; 03.06.2017
git add -u состоит в том, что у файла уже должна быть версия (он должен быть частью репо). Так, может быть, это то, где что-то терпит неудачу? Я пробовал это с 2.15.0, так что, возможно, была какая-то другая ошибка, влияющая на это в течение короткого времени.
- person John Szakmeister; 28.11.2017
git read-tree --empty; git add .. Любые отслеживаемые файлы, которые будут игнорироваться .gitignore, будут удалены при его использовании. Документация теперь рекомендует git add --renormalize .
- person vossad01; 10.06.2018
git config --get core.autocrlf?
- person John Szakmeister; 19.03.2021
false. Но даже когда он пытается преобразовать окончания строк, это происходит слишком быстро, например, 5 секунд для 1000 файлов. В конце концов я использовал notepad++ для глобального поиска и замены.
- person Roger Far; 19.03.2021
.gitattributes? Я никогда не видел, чтобы это было реальной проблемой, даже под Windows. Похоже, вы пропустили шаг или что-то происходит с окружающей средой. И 5 секунд на 1000 вполне возможно. Преобразование чертовски просто, и Git ужасно эффективен в том, что он делает. Извините, это было проблемой для вас, хотя.
- person John Szakmeister; 20.03.2021
Убедитесь, что у вас нет ожидающих изменений в репозитории:
$ git status
$ git stash
Измените .gitattributes, чтобы интерпретация CRLF изменилась:
$ echo "*.txt text" >>.gitattributes
$ git commit -m "Made .txt files a subject to CRLF normalization." -- .gitattributes
Удалить данные из индекса и обновить рабочий каталог:
$ git rm --cached -r .
$ git reset --hard
Ознакомьтесь с исправлениями CRLF, которые предлагает Git:
$ git ls-files --eol
$ git status
$ git diff
Согласен с решением Git:
$ git add -u
$ git commit -m "Normalized CRLF for .txt files"
Перезагрузите изменения, как если бы было выполнено чистое клонирование:
$ git rm --cached -r .
$ git reset --hard
--eol для git ls-files является новой в Git 2.8 (уже не новой, но некоторые люди все еще страдают от Git 1.7, даже в конце 2018 года!).
- person torek; 21.09.2018
git ls-files --eol помогает проверить правильность окончания строк во всех файлах, спасибо!
- person forumulator; 05.03.2021
Настройки .gitattributes повлияют только на новые коммиты. Если в этом репозитории нет опубликованной истории (нет других зависящих от него), вы можете просмотреть всю историю. В Unix/Linux вы можете использовать dos2unix(1) для исправления всех файлов в сочетании с find(1) и с помощью перезаписи истории filter-branch (см. обсуждение в git book) можно даже подчистить полную историю проекта.
Используйте с особой осторожностью на свежем клоне. Свяжитесь с любым, у кого может быть клон, и посоветуйте им, что вы хотите сделать.
Опция * text=auto в .gitattributes оставляет репозиторий Git в «недопустимом состоянии», если он содержит файлы с окончаниями строк CRLF (Windows), которые теперь помечены как текст (см. https://marc.info/?l=git&m=154484903528621&w=2). Стандартная опция перенормировки не работает корректно с фильтрами LFS, поэтому инструкции в других ответах или, например, в https://help.github.com/en/articles/dealing-with-line-endings работают некорректно. Вместо этого эти шаги сработали для нас:
Ситуация:
Также изменил -crlf на -text для отслеживаемых файлов LFS, не уверен, что это необходимо.
Параметр конфигурации merge.renormalize может оказаться полезным.
