4

I have started to use git for my projects, when I create a project it has a config folder containing configuration files:

application/config/config.php
application/config/database.php
application/config/routes.php

When I first commit I want these files (with their defaults) to be committed, so they exist in the repository as the "default" configurations and if I clone to repository I get these files. When I update them to contain my configuration variables (for the version I'm developing on) I don't want them to be updated in the repository, I want them to remain in their default state in the repository.

I have tried first committing them in their default state and then adding them to my .gitignore file, like so:

application/config/*

Now when I commit my configuration files aren't committed (yay!) however the original defaults disappear, the folder application/config/ no longer exists in my repository.

I assume I'm missing something obvious here, but I'm very inexperienced with git.

How can I commit the configuration files on my first commit but never again with them remaining in the repository in their default state?

sam
  • 5,459
  • 6
  • 32
  • 53

1 Answers1

8

You could, once versioned, update their index:

 git update-index --assume-unchanged application/config/config.php

Or you could even update the index more permently:

 git update-index --skip-worktree application/config/config.php

(as show in "git update-index --assume-unchanged and git reset")


The other solution is to not version those final config file (since their content may vary as you pointed out), but to use a filter driver:

filter driver

You would versioned:

  • template files (application/config/config.tpl)
  • config value files (one default, and other for your different environments)
  • a script able to recognize the content of a config file (since it won't have its path) and generate the final config files according to the current environment.
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you, the worktree command worked perfectly, I'll look at the second solution as something for my long term git usage. Thanks! – sam Feb 19 '12 at 01:50