Keeping git from requiring commit of changes

Question

We have several config files in a project that 3 people are working on. However, those config files contain several lines that differ for each of us and so should not be changed or overwritten by commits. Yet Git won't let us pull changes from the other people unless we commit those config file changes which then means that it changes the other members configs again.

Being new to Git it seems that we either need to create branches and merge them every commit to update our code - or use .gitignore. What is the proper way to handle this situation? We all need constant access to the changes that the other members make.

Answer 1

Don't check in the config file.

If need be you could have a config.example, which each of you copies to an untracked config file - this is how most projects handle this.

Answer 2

I have been discovering the value of using sensible defaults in the application along with an optional config file that is ignored by version control. An example config file may be checked in, but with a different name; usually "config.example.yml" (or whatever extension makes sense for you).

Answer 3

Tracking an example config file is generally a good approach. You can then have an untracked local copy. You can use githooks to help you apply the differences. You can have the post-merge and post-checkout (and maybe even post-commit) recopy the tracked to the untracked, and possibly apply changes to create your customized version. How exactly you do the last bit is up to you - it's a script. A few calls to sed -i might do it though.

Another possibility, if you are able to use two config files, or the config files have some sort of "include" directive, is to have one tracked and one untracked.

Answer 4

You could also use the serious git-fu known as "rebase --onto", as outlined here.

As I understand this approach, you have your own config changes in a single commit on your own branch. Work on your own branch. Every so often you lop the branch off above your config commit, and sew it back onto master. Repeat as necessary.

A good diagram of this is in Scott Chacon's forthcoming Pro Git book.

I think this is one of those things with Git that it's best to figure out once. Use git config --global alias.lop 'rebase --onto etc. etc.' so that you can just type eg. git lop in the future.

Answer 5

I'm pretty sure that I recommend against the following technique, but...

You could use filter drivers to set the config file appropriately for each developer. The checked in file could contain a generic value, and each developer would have a smudge rule that changes it for them.

For example, if the line in the file named 'config-file' you want to modify on a per-developer basis looks like:

config: default

Then a developer would have this in their local .git/info/attributes:

config-file filter=modify-config

and something like this in .git/config:

[filter "modify-config"]
    smudge = sed -e 's/^config:.*/config: developers value/'
    clean = sed -e '/^config/s/.*/config: default/'