git игнорировать конфигурационные файлы

Это вопрос всплывал уже несколько раз. Лично мне нравится openbsd-style.

Т.е. у тебя есть 'config.conf' (в репо и с базовами настройками) и 'config.conf.local' который не в репо и для пользовательских настроек, который может менять/«перетирать» базвые настройки.

Часто реализуется через:

#my config

# ...

include "*.local"

Знаю про .gitignore, но если файл уже добавлен в репозиторий

дык, вынэми

Через .gitattributes это нельзя решить?

Поясни. Мне он нужен в репозитории, чтобы при clone можно было сразу собирать и запускать программу без лишних действий. Сейчас есть config.example, который после клона надо скопировать в config и использовать. Этот config уже в .gitignore. Но это усложняет развёртывание и отслеживание изменений: добавляется лишний шаг для настройки окружения; нужно постоянно отслеживать добавление новых опций в config.example и копировать их в config.

Альтернатива — написать скрипт, который будет делать git update-index --skip-worktree config, его надо будет запускать после clone. Но, как я понимаю, эта штука очищается при смене ветки, опять же лишний шаг. Мне надо что-то вроде skip-worktree, только на уровне репозитория, а не его локальной копии, чтобы работало сразу после clone, checkout и тд.

уже был такой вопрос. Кроме уже озвученного, обычно просто есть .conf.example, пользователь его копирует и убирает .example

после копирования проекта его надо собирать? Или он сразу готов к использованию?

Если надо - то где-то в make запилить echo filelist >> .gitignore

в таких случаях делаю вариант с .local, типо есть глобальный конфиг и на других конфигах переопределяются только некоторые критические опции (базы и пр.)
тут уже в зависимости от потребностей можно включить в гит (release.conf/debug.conf/test.conf/... например, и инклудить ${CUR_ENV}.conf ) или не включать и сделать как в примере выше с *.local

Вариант только один - храни в репе foo.conf.default, пользователи пусть меняют foo.conf которого в репе нет.

А логика работы с этим может быть разная, самое правильное - foo.conf.default просто повторяет зашитые в программу настройки (при этом может быть вообще весь закомментирован), программа читает только foo.conf, таким образом решаются и проблемы с репозиторием, и пользователю максимально удобно - можно скопировать foo.conf.default в foo.conf и менять что-то относительно умолчальных опций, а можно создать foo.conf с нуля. Пример такого - tor.

Можно и по-другому: например, читать foo.conf, если его нет - foo.conf.default. Можно что-то куда-то инклудить. Но это кривее.

Неудобно, потому что добавляется лишний шаг перед началом работы и не отслеживаются изменения в конфигах. Но, видимо, в гите нет того, что я хочу, гугл тоже не помог. Жаль, фича-то очевидная.

в гите нет того, что я хочу

Почему этим система контроля версий должна заниматься? Логичнее для программы работать без конфига, но с дефолтными настройками. Или создавать дефолтный конфиг при первом запуске.

Неудобно, потому что добавляется лишний шаг перед началом работы

Шага нет, всё работает из коробки. При изменении конфига его надо создавать - да, по-другому никак.

и не отслеживаются изменения в конфигах

а это противоречит

При этом без специальных усилий он не должен быть способен закоммитить эти изменения

При этом никто не мешает пользователю добавить свои конфиги (без .sample) в локальный репозиторий и отслеживать их как угодно.

Почему этим система контроля версий должна заниматься?

Потому что это её работа — управлять исходными файлами проекта. Собстевнно git это почти умеет — там есть функционал skip-worktree, просто эту настройку нельзя сохранить в репозитории в каком-нибудь .gitattributes.

Логичнее для программы работать без конфига, но с дефолтными настройками. Или создавать дефолтный конфиг при первом запуске.

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

Ты хочешь кнопку «сделай мне хорошо», это понятно. Но пока ты не понимаешь, как она работает в деталях, тебе всё будет не то.

Допустим, пользователь получил исходники. Пусть магия в VCS как-то сгенерировала конфиг из примера. Теперь пользователь меняет настройки, пользуется. Потом выкачивает обновления, в которой часть параметров изчезает, и добавляются новые. У пользователя старый конфиг. Как магия в VCS должна актуализировать конфиг? Что будет если программа требует всех настроек? Она просто упадёт из-за того, что в конфиге пользователя нет нужных?

Допустим, пользователь получил исходники.

Не пользователь, а разработчик. Пользователя это всё не касается, там уже идёт релиз дистрибутива программы и c git-ом он никак не взаимодействует.

Пусть магия в VCS как-то сгенерировала конфиг из примера. Теперь пользователь меняет настройки, пользуется. Потом выкачивает обновления, в которой часть параметров изчезает, и добавляются новые. У пользователя старый конфиг. Как магия в VCS должна актуализировать конфиг?

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

Что будет если программа требует всех настроек? Она просто упадёт из-за того, что в конфиге пользователя нет нужных?

Да, упадёт. В идеале на старте, в реальности может не на старте, не суть.

Есть два варианта - вообще выкинуть этот конфиг из репы и тогда будет работать gitignore (то есть где-то в хаутушке к своему проекту ты пишешь «перед началом работы сделайте config.conf с вот таким содержимым») или делать на локальной копии git update-index --assume-unchanged config.conf, но это предстоит делать руками и гарантий что клиент это сделает (или что не отменит в определенный момент и не запушит этот config.conf) нет никаких.

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

Если твои конфиги меняются так часто, что неудобно обновлять руками, то возможно что лучше вынести их на разделяемый ресурс, например в БД.

Приложение при старте читает конфиг app_config.cfg, если его нет, то читает app_config.cfg-example.

Файл app_config.cfg-example лежит в репозитории. Файл app_config.cfg лежит в игнор листе.

Если кому-либо нужен кастомный конфиг, он копирует app_config.cfg-example в app_config.cfg и правит его.

Генерируй(копируй) конфиги системой сборки в build директорию (куда собирается программа). И пусть там меняет как ему хочется.

чтобы при clone можно было сразу собирать и запускать программу без лишних действий.

иметь в репозитории config.name.default, при запуске два раза пробегаться - по cofig.name.default и затем по config.name, оверрайдя изменения из default'а нормальным конфигом.