4

Suppose I create some widget, and decide to share it with Github. In this widget project, there's some configuration/preferences file. I need to share what the values being set are, so that if anyone else wished their own widget they'd know what to set. But I don't necessarily want or need to share my own settings.

This would be a case in which some/all of the settings have no concept of a 'default' - they all need to be explicitly set by the programmer.

I thought I was going to find an answer in this question, but really that (or at least it's answers) are more focussed on keeping things secret. I don't need to share in confidence - I just don't need to share.


In essence, I need to deploy Foo := 'Bar', but commit/push/share Foo :=.

What's the best way of handling this in Git?

Some possible solutions:

  1. Commit the unpopulated file; don't include in later commits with preferences set. Disadvantage: if I add a new setting later, need to remove all values to commit it, and then set them again.
  2. Set the values by import/inclusion (as applicable for the language) to ensure an upfront (and less confusing than it might otherwise be) error; clearly state requirements in a readme. Disadvantage: noone likes errors.
  3. Branches? I've never really had the need to use multiple, but I have a feeling the 'right' way to do this might be an un-pushed 'deploy' branch with the values set, and unset in the pushed 'master' branch; just deal with the merge conflicts as they arise on adding new properties? Maybe? Same disadvantage as (1) really, but maybe it's the better practice?
  • Why do you think there no acceptable default values? I can't really think of anything that can't have a "dummy" value e.g. 127.0.0.1 for an IP address or fakedomain.com for a domain name. – Dave Nay Jul 18 '15 at 15:37
  • @DaveNay Okay, dummy values, sure. But I suppose then my situation is even slightly worse - I need to commit different values, to those I deploy. I guess I was wrong to focus on needing "no value" -- my issue really is "deploy different to what I share". e.g. If I deploy name := 'Ollie', I would commit something like name := 'Your name here'. – OJFord Jul 18 '15 at 15:41
  • Downvote reason? – OJFord Jul 18 '15 at 16:10
4

I would go with a modified version of scenario 1. Instead of adding your real configuration file to the repo, add a prototype config file. When the widget first runs, it detects if the config file is present or not. If not present, it renames the prototype file and then loads it. The prototype file can have sane default values (might no "work" but don't crash the widget).

This will allow you to have your local config file (which is never committed, but should probably be backed up) as well as a version that can be publicly pushed that doesn't contain your private information.

  • Thanks, I like this solution. Still two files to edit on any change, but I suppose that's unavoidable really since they'd almost certainly conflict every time. – OJFord Jul 18 '15 at 16:14
3

So the idea is: If I check out your git repository, I get a config file template, where I need to fill in the proper values, and you cannot know what the correct values would be for me. In that case, your config file should obviously have plenty of documentation, and building / running the project should fail as early as possible for me if I don't make the necessary changes. It should also be hard for me to commit my fixed config file so it doesn't get distributed by accident (for the same reason that you don't commit your actual config file).

I'd check in a template file, make sure that the whole project is set up so that the template file doesn't become part of the build, and add instructions for me how to create the correct config file, and setup your project so that the correct config file is needed to build. You can else setup git so that it will ignore the config file.

  • Oh nice, thanks! That makes things clearer actually. So I could commit the .gitignore with the config file to ensure others don't accidentally commit it -- and this also sets an expected name, which I can then look for, if it doesn't exist, error with "no config file, see template" or similar. – OJFord Jul 18 '15 at 23:38
  • There's still an issue with detecting/merging when fields are added - but the more I think about it the more I realise that's really just a disadvantage of using a source file as opposed to db. – OJFord Jul 18 '15 at 23:40
1

My first thought is: Don't store the populated config file in git at all. Put the unpopulated file in git and on installation or first run, create the populated file in another place. If the configuration is user specific, this other place would be in:

  • Windows: %APPDATA%
  • Linux: a dot file or a dot folder in the user's home directory. Something like ~/.myapp_config
  • Mac OS X: the user's Library folder, probably in a subdirectory for your app.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.