Распределение конфигурации git с кодом

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

Как мне настроить это?

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

Ответ 1

Я всегда нашел свойство конфигурации autocrlf проблематичным. (как выражено в моем ответе Git 1.6.4 beta в Windows (msysgit) - завершение линии Unix или DOS)

он не только делает некоторые сложные слияния
он может меняться в зависимости от оболочки, используемой в пределах одной среды
у него также есть проблема с Git статусом
и svn import.

Примечание: msysgit issue 538 для установки его в true (который является значением по умолчанию, установленным установщиком MSysgit), но я не убедило.

Я предпочел бы одно из трех следующих решений для:

настройка одного стиля конца строки
передача этой конфигурации через различные репозитории Git

1. Используя новый конфигурационный параметр core.eol (1.7.2 +)

Устанавливает тип окончания строки для использования в рабочем каталоге для файлов, у которых есть свойство текста.
Альтернативами являются "lf", "crlf" и "native", где используется окончательная строка на основе платформы.
Значение по умолчанию - native.

2. a checkout/check .gitattribute. См. gitattributes man-страница: crlf или core.autocrlf - это способ записи в файле .gitattributes того, что ранее было локальным атрибутом конфигурации.

3. a Git драйвер фильтра атрибутов, который может:

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

Ответ 2

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

ln -s .git/config git-config
git add git-config
git commit -m "Now tracking git config file"

Ответ 3

Может быть лучшим способом использовать hardlink:

В системе * nix или OS X:

ln .git/config git-config
git add git-config
git commit -m "Now tracking git config file"

В Windows на NTFS файловой системе System:

mklink /H git-config .git\config
git add git-config
git commit -m "Now tracking git config file"

Но мы должны помнить, что при клонировании проекта применяются настройки для выполнения обратной процедуры:

В системе * nix или OS X:

git clone FROM_PROJ_URL
rm .git/config
ln git-config .git\config

В Windows на NTFS файловой системе System:

git clone FROM_PROJ_URL
del .git\config
mklink /H .git\config git-config

Ответ 4

.git/config может быть локально заменен на ~/.gitconfig.

Итак, как часть сборки, Makefile или обеспечения script, вы можете предложить изменение для пользователей в их ~/.gitconfig или загрузить локальный script .gitconfig через git config.

Например, создайте новый .gitconfig с некоторыми настройками и загрузите его:

git config --local include.path "/path/to/.gitconfig"

или попросите пользователей иметь в своих ~/.gitconfig следующие строки:

[include]
    path = .gitconfig

Если вы используете Vagrant как часть вашего дистрибутива кода, вы можете загрузить git config из Vagrantfile с помощью:

system('GIT_TRACE=1 git config --local include.path "$(git rev-parse --show-toplevel)/git/gitconfig"');

затем скопируйте конфигурацию git в git/gitconfig, поэтому каждый раз, когда пользователи запускают подготовку своей виртуальной машины, этот файл будет загружаться автоматически для своего git на хост-компьютере (например, для принудительного использования core.filemode для отключения, поэтому Windows не будет иметь проблем с правами на файл).

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

# Drupal git normalization
# @see https://www.kernel.org/pub/software/scm/git/docs/gitattributes.html
# @see https://www.drupal.org/node/1542048

# Define text file attributes.
# - Treat them as text.
# - Ensure no CRLF line-endings, neither on checkout nor on checkin.
# - Detect whitespace errors.
#   - Exposed by default in `git diff --color` on the CLI.
#   - Validate with `git diff --check`.
#   - Deny applying with `git apply --whitespace=error-all`.
#   - Fix automatically with `git apply --whitespace=fix`.

*.css     text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2
*.html    text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2 diff=html
*.js      text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2
*.json    text eol=lf whitespace=blank-at-eol,-blank-at-eof,-space-before-tab,tab-in-indent,tabwidth=2

# Auto-detect text files, ensure they use LF.
*         text=auto eol=lf

# Define binary file attributes.
# - Do not treat them as text.
# - Include binary diff in patches instead of "binary files differ."
*.gz      -text diff