Сделать Git использовать CRLF на своих линиях слияния <<<<<<< HEAD "

Ответ 1

Можно ли запросить Git использовать CRLF вместо LF в конце строк, которые он помещает в файл, когда ему нужно слияние?

Это... возможно, из git 2.7.2+ (февраль 2016 г.).
И вам ничего не нужно делать.

См. commit 15980de, commit 86efa21 (27 января 2016) Йоханнес Шинделин (dscho).
^{(объединено Junio ​​C Hamano - gitster - в commit ab2c107, 17 февраля 2016 г.)}

merge-file: пусть маркеры конфликта соответствуют концу строки контекста

При объединении файлов с окончанием строки CR/LF маркеры конфликтов должны сопоставьте их, чтобы выходной файл не имел смешанных окончаний строки.

Это особенно интересно в Windows, где некоторые редакторы получают действительно смущены смешанными окончаниями линий.

Оригинальная версия этого патча от Beat Bolli уважалась core.eol, и последующее улучшение этого разработчика также уважало gitattributes.
Этот подход был субоптимальным, хотя: git merge-file был изобретен как замена замены для слияния GNU и, как таковая, не имеет проблем с эксплуатацией вне любого репозитория!

Еще одна проблема с первоначальным подходом была указана Юнио Hamano: устаревшие репозитории могут передавать свои текстовые файлы, используя Окончания строк CR/LF (и core.eol и gitattributes дали бы нам ложное впечатление есть). Следовательно, гораздо лучший подход заключается в том, чтобы просто сопоставляйте окончания контекстной строки, если есть.

Нам вообще не нужно смотреть на весь контекст:

• Если все файлы LF-only, или все они имеют окончания строки CR/LF, достаточно посмотреть только одну строку, соответствующую этому стилю.
• И если контуры строк все равно смешаны, все равно можно имитировать только одну строку eol: мы просто добавим в кучу смешанных строк, и мы ничего не можем с этим поделать.

Итак, что мы делаем: мы смотрим на линию, предшествующую конфликту, падая вернемся к предыдущей строке, если она была последней строкой и не имела линия заканчивается, возвращается к первой строке, сначала в первой пост-изображение, затем второе изображение после изображения и, наконец, предварительное изображение.
Если мы найдем непротиворечивый стиль CR/LF (или нерешительный) конца строки, мы сопоставим что в противном случае мы используем окончания строки только для LF для маркеров конфликта.

Заметим, что хотя верно, что должны быть не менее двух строк, мы может смотреть (иначе конфликт не будет), то же самое не верно для окончаний строк: три файла, о которых идет речь, могут состоять из одиночная строка без какой-либо строки, каждая. В этом случае мы возвращаемся к используя только LF.

Ответ 2

Нет установки, которая управляет окончаниями строк, используемыми для "< < < < маркеры в git; они жестко закодированы для использования '\n' в исходном коде git (см. строка 173 из файла xmerge.c).

Если вы установите для параметров "eol" или "core.eol" значение "crlf", тогда "< < < маркеры будут иметь \r\n окончания строки в файле (это происходит во время шага smudge/clean filter после кода, приведенного выше), но это имеет существенный побочный эффект: файлы будут" нормализованы" на своем пути в репозиторий, поэтому вы будете фиксировать файлы с окончанием строки unix.

Это скорее всего не то, что вы хотите в проекте .Net, как в примере выше.

Итак, у меня нет хорошего ответа для вас, извините.

Ответ 3

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

Например, отредактируйте файл .gitattributes в корне проекта git так, чтобы он содержал что-то вроде этого:

*.cs         eol=crlf
*.config     eol=crlf