How to handle project config files in source control

Question

When downloading a project under source control to a new developer or a new machine, it should compile out of the box.
But in any software project, there are configuration files that need local changes for various reasons, database connections and so forth.
I want copies of these files under source control so the project is complete for a new installation.

I don't want those local changes uploaded and I don't want those changes downloaded to and breaking an existing installation.
You can tell it to ignore those files, but then it wants to ignore them globally, not just locally.

My best solution so far is to create a copy (config.sample) and keep that in source control while ignoring the live copies.

Seems like there should be a better solution.

Answer 1

From Feb 2020, by Michael

It is quite common for users to want to ignore the changes to a file that Git tracks.

Yup.

Common scenarios for this case are IDE settings and configuration files, which should generally not be tracked and possibly generated from tracked files using a templating mechanism.

Yup.

However, users learn about the assume-unchanged and skip-worktree bits and try to use them to do this anyway.

That was my next step.

This is problematic, because when these bits are set, many operations behave as the user expects, but they usually do not help when git checkout needs to replace a file.

There is no sensible behavior in this case, because sometimes the data is precious, such as certain configuration files, and sometimes it is irrelevant data that the user would be happy to discard.

Since this is not a supported configuration and users are prone to misuse the existing features for unintended purposes, causing general sadness and confusion, let's document the existing behavior and the pitfalls in the documentation for git update-index so that users know they should explore alternate solutions.

In addition, let's provide a recommended solution to dealing with the common case of configuration files, since there are well-known approaches used successfully in many environments.

The git update-index man page now includes:

Users often try to use the assume-unchanged and skip-worktree bits to tell Git to ignore changes to files that are tracked. This does not work as expected, since Git may still check working tree files against the index when performing certain operations. In general, Git does not provide a way to ignore changes to tracked files, so alternate solutions are recommended.

For example, if the file you want to change is some sort of config file, the repository can include a sample config file that can then be copied into the ignored name and modified.

And we are left right where we started. But at least we can stop looking for a solution.

Answer 2

My best solution so far is to create a copy (config.sample) and keep that in source control while ignoring the live copies.

That is what I usually do, but I add a build script, which:

• will call a senv script called by the build script, in charge of setting the right environment variable
• can copy the config.sample into a config file (ignored by Git), with reasonable defaults
• can check the pre-requite tools
• will do the actual build

That way, I do not have to remember what I am supposed to do right after a clone: the build script will tell me if anything is missing or needs to be edited/configured.