Попытка исправить концы строк с помощью git filter-branch, но безуспешно

Документация git для gitattributes теперь документирует другой подход для «исправления» или нормализации всех окончаний строк в вашем проект. Вот суть:

$ echo "* text=auto" >.gitattributes
$ git add --renormalize .
$ git status        # Show files that will be normalized
$ git commit -m "Introduce end-of-line normalization"

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

manual.pdf -text

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

weirdchars.txt text

При этом используется новый флаг --renormalize, добавленный в git v2.16.0, выпущенном в январе 2018 г. Для более старых версий git есть еще несколько шагов:

$ 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"

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

# From the root of your repository remove everything from the index
git rm --cached -r .

# Change the autocrlf setting of the repository (you may want 
#  to use true on windows):
git config core.autocrlf input

# Re-add all the deleted files to the index
# (You should get lots of messages like:
#   warning: CRLF will be replaced by LF in <file>.)
git diff --cached --name-only -z | xargs -0 git add

# Commit
git commit -m "Fixed crlf issue"

# If you're doing this on a Unix/Mac OSX clone then optionally remove
# the working tree and re-check everything out with the correct line endings.
git ls-files -z | xargs -0 rm
git checkout .

Моя процедура работы с окончаниями строк следующая (проверено в бою на многих репозиториях):

При создании нового репо:

• поместите .gitattributes в самый первый коммит вместе с другими типичными файлами как .gitignore и README.md

При работе с существующим репо:

• Создать / изменить .gitattributes соответственно
• git commit -a -m "Modified gitattributes"
• git rm --cached -r . && git reset --hard && git commit -a -m 'Normalize CRLF' -n"
  • -n (--no-verify is to skip pre-commit hooks)
  • Мне приходится делать это достаточно часто, поэтому я определил это как псевдоним alias fixCRLF="..."
• repeat the previous command
  • yep, it's voodoo, but generally I have to run the command twice, first time it normalizes some files, second time even more files. Generally it's probably best to repeat until no new commit is created :)
• несколько раз переходите между старой (непосредственно перед нормализацией) и новой ветвью. После переключения ветки иногда git находит еще больше файлов, которые необходимо перенормировать!

В .gitattributes я явно объявляю все текстовые файлы как имеющие LF EOL , поскольку обычно инструменты Windows совместимы с LF, в то время как инструменты, отличные от Windows, несовместимы с CRLF (даже многие инструменты командной строки nodejs предполагают LF и, следовательно, могут изменять EOL в ваших файлах).

Содержание .gitattributes

Мой .gitattributes обычно выглядит так:

*.html eol=lf
*.js   eol=lf
*.json eol=lf
*.less eol=lf
*.md   eol=lf
*.svg  eol=lf
*.xml  eol=lf

Чтобы выяснить, какие отдельные расширения отслеживаются git в текущем репо, посмотрите здесь

Проблемы после нормализации

Как только это будет сделано, есть еще одно распространенное предостережение.

Допустим, ваш master уже обновлен и нормализован, а затем вы оформляете заказ outdated-branch. Часто сразу после проверки этой ветки git отмечает многие файлы как измененные.

Решение - сделать фальшивую фиксацию (git add -A . && git commit -m 'fake commit'), а затем git rebase master. После перебазирования фальшивая фиксация должна исчезнуть.

git status --short|grep "^ *M"|awk '{print $2}'|xargs fromdos

Объяснение:

• git status --short

  Это отображает каждую строку, о которой git знает и не знает. Файлы, которые не находятся под управлением git, помечаются в начале строки знаком «?». Измененные файлы помечаются буквой M.

• grep "^ *M"

  Это отфильтровывает только те файлы, которые были изменены.

• awk '{print $2}'

  Это показывает только имя файла без каких-либо маркеров.

• xargs fromdos

  Это берет имена файлов из предыдущей команды и запускает их через утилиту fromdos для преобразования окончаний строк.

Вот как я исправил все окончания строк во всей истории, используя git filter-branch. Символ ^M необходимо вводить с помощью CTRL-V + CTRL-M. Я использовал dos2unix для преобразования файлов, так как это автоматически пропускает двоичные файлы.

$ git filter-branch --tree-filter 'grep -IUrl "^M" | xargs -I {} dos2unix "{}"'

«| Xargs fromdos» считывает из стандартного ввода (файлы, которые находит find) и использует его в качестве аргументов для команды fromdos, которая преобразует окончания строк. (Является ли fromdos стандартным для этих сред? Я привык к dos2unix). Обратите внимание, что вы можете избежать использования xargs (особенно полезно, если у вас достаточно файлов, и список аргументов слишком длинный для xargs):

find <path, tests...> -exec fromdos '{}' \;

or

find <path, tests...> | while read file; do fromdos $file; done

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

Один из простых способов получить ошибку «файл не найден» для сценария - использовать относительный путь - используйте абсолютный. Точно так же вы можете получить ошибку разрешений, если вы не сделали свой скрипт исполняемым (chmod + x).

Добавляйте комментарии, и я постараюсь помочь вам с этим разобраться!

хорошо ... в cygwin у нас нет легко доступного fromdos, и этот awk substeb взрывается вам в лицо, если у вас есть пробелы в путях к измененным файлам (которые у нас были), поэтому мне пришлось сделать это несколько иначе:

git status --short | grep "^ *M" | sed 's/^ *M//' | xargs -n 1 dos2unix

Престижность @lloyd за большую часть этого решения

Выполните следующие действия, если ни один из других ответов вам не подходит:

1. Если вы работаете в Windows, сделайте git config --global core.autocrlf true; если вы используете Unix, сделайте git config core.autocrlf input
2. Запустите git rm --cached -r .
3. Удалите файл .gitattributes
4. Запустите git add -A
5. Беги git reset --hard

Тогда ваш местный должен быть чистым.