What's the easiest way to deal with project configuration files?

Question

It's very common to have at least one configuration file in any project. Every time I share project with git, I have the same problem with:

• sensitive information (each developer have different DB passwords etc)
• task specific information (when developer works on certain task where one needs to change some settings)

Obviously, configs have to be ignored somehow to prevent developer specific data to flood main repository. Now there are several ways I used to use, each with some flaws:

• .gitignore the config files
  • the most basic way
  • when developer clones repo, config file is missing and one has to find out where configs were recreate them
• config file isn't ignored. It contains some dummy info and each developer either untracks and puts it to his .git/info/exclude or set git update-index --assume-unchanged ... to the file
  • files are available for anyone who clones repo
  • it contains advanced techniques which could confuse people that work with git for the first time
  • when someone commits config files by accident, it won't allow people to pull/fetch (as excludes don't work the same way as .gitignore)
• distribute config files suffixed with, for example, _original while having the real files in .gitignore. Each developer then renames files to real names
  • files are available for anyone who clones repo
  • one has to search for all configs throughout application and rename them

Are there any other, possibly, better ways to handle this? I suspect I'm missing something, some plugin at least.

Answer 1

Filter drivers are the "automatic" way of implementing option 3, as detailed in "when you have secret key in your project, how can pushing to GitHub be possible?":

The smudge script will, on checkout:

• detect the right config files to modify
• fetch the information needed (best kept outside any Git repo) and will replace the template values by the actual one.

From there the developers can make any kind of modification they want to those config files.
It won't matter, because the clean script will, on commit, restore the content of that file to its original (template) value. No accidental push there.

Answer 2

The way we did it on the last project i worked on was to have a master config file that loaded a users local config file if it was present which could overwrite the defaults set in the master if specified and declared its own config info if not present in master. The local file was added to gitignore. That way all common stuff could all be shared and some config always present and each developer can modify their local.