Рекомендации по кросс-платформенной конфигурации git config?

Контекст

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

[core]
    autocrlf = true
    safecrlf = false

Проблема

Эти настройки также применяются на платформе GNU/Linux, что вызывает неясные ошибки.

Вопрос

Каковы некоторые рекомендации по работе с этими различиями в конфигурации в конфигурационных файлах?

Предлагаемое решение

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

Ответ 1

Я рассмотрел эту конфигурационную настройку (crlf) в вопросе:
распределение конфигурации git с кодом.

Вывод:

  • checkout/check.gitattributes файлы
  • список всех типов, которые явно нуждаются в таком преобразовании.
    Например:
*.java +crlf
*.txt +crlf
...
  • избегать любых преобразований типов файлов, которые ему не нужны, из-за различного побочного эффекта такого преобразования при слияниях, git status, оболочки и svn import (см. "распределение конфигурации git с кодом "для ссылок и ссылок).
  • избегайте преобразования crlf вообще, если вы можете.

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

Как указано в вопросе Git: Как поддерживать две ветки проекта и объединять только общие данные?:

ваша жизнь будет намного проще, если вы поместите системно-зависимый код в разные каталоги и рассмотрите кросс-платформенные зависимости в системе сборки (Make файлы или все, что вы используете).

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

Ответ 2

Никогда не включайте autocrlf, это не вызывает ничего, кроме головных болей и печалей.

Нет оправданий использовать \r\n для окон, все приличные редакторы (по определению) могут обрабатывать \n.

Ответ 3

Я думаю, что вы должны иметь .gitconfig в зависимости от операционной системы, которую использует пользователь. Пользователям Windows не требуется autocrlf вообще, пока пользователи Linux делают это. Например. сохранить текстовые файлы с помощью crlf и Git автоматически конвертировать файлы взад и вперед для пользователей Linux.

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