Asked  7 Months ago    Answers:  5   Viewed   24 times

A common scenario when I develop is that the codebase will have several config files which require machine specific settings. These files will be checked into Git and other developers will always accidentally check them back in and break someone else's configuration.

A simple solution to this would be to just not check them in to Git, or even to additionally add a .gitignore entry for them. However, I find that it is much more elegant to have some sensible defaults in the file which the developer can modify to suit his needs.

Is there an elegant way to make Git play nicely with such files? I would like to be able to modify a machine-specific configuration file and then be able to run "git commit -a" without checking that file in.



Have your program read a pair of configuration files for its settings. First, it should read a config.defaults file that would be included in the repository. Then, it should read a config.local file that should be listed in .gitignore

With this arrangement, new settings appear in the defaults file and take effect as soon as it's updated. They will only vary on particular systems if they're overridden.

As a variation on this, you could have just a general config file that you ship in version control, and have it do something like include config.local to bring in the machine-specific values. This introduces a more general mechanism (versus policy) in you code, and consequently enables more complicated configurations (if that's desirable for your application). The popular extension from this, seen in many large-scale open-source software, is to include conf.d, which reads configuration from all the files in a directory.

Also see my answer to a similar question.

Tuesday, June 1, 2021
answered 7 Months ago

For me it depends on who is going to touch that configuration.

If it is developers, then PHP files are the best, as they do not require any additional parsing.

If it is technical users (for example, other developers, or sysadmins) then there is choice: complicated config file would better go with a structured file, like XML or YAML, as there is less chance to break the PHP code if something goes wrong (and you can report a specific parsing error with suggestions how to fix). Simple choices can be written with PHP (but here if someone forgets a quote character the program will fail with strange errors, or with no errors at all if errors go to the log only!).

If it is final users... then no configuration files should be exposed at all, in my opinion. You need to provide an installer which will handle everything (and generate the machine-readable configuration files or write things to the db).

Saturday, May 29, 2021
answered 7 Months ago

If you want to exclude files that are specific to your process (such as Vim temporary files), edit the (local) file .git/info/exclude and add your exclusion patterns there. This file is designed for developer-specific exclusions rather than .gitignore, which is designed for project-wide exclusions.

The short summary is, everybody should agree on what is added to .gitignore. For files where you don't agree, use .git/info/exclude.

Saturday, June 12, 2021
answered 6 Months ago

Try putting the configSections as the first child element of configuration, because configSections should be the first element of configurations

So your config file will go like this:


    <sectionGroup name="userSettings" type="System.Configuration.UserSettingsGroup, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <section name="Vegi_Manager.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=, Culture=neutral, PublicKeyToken=b77a5c561934e089" allowExeDefinition="MachineToLocalUser" requirePermission="false"/>

    <add name="ConStr" connectionString="Integrated Security=false;Persist Security Info=False;User ID=funny;password=veryfunny;Initial Catalog=vegimanager;Data Source=.sqlexpress;"/>

      <setting name="FIRMNAME" serializeAs="String">
      <setting name="FIRMADDRESS" serializeAs="String">
      <setting name="FIRMCITY" serializeAs="String">
      <setting name="FIRMSTATE" serializeAs="String">
      <setting name="FIRMPHONE" serializeAs="String">
      <setting name="FIRMMOBILE" serializeAs="String">
      <setting name="FIRMEMAIL" serializeAs="String">
      <setting name="FIRMTIN" serializeAs="String">
      <setting name="FIRMPAN" serializeAs="String">
      <setting name="FIRMMANDITAXNO" serializeAs="String">
      <setting name="INITIALFONFIGDONE" serializeAs="String">
      <setting name="FIRMJURISDICTION" serializeAs="String">
      <setting name="FIRMBANKDETAILS" serializeAs="String">
      <setting name="FIRMDETAILS" serializeAs="String">
      <setting name="BILLFORMATNO" serializeAs="String">
      <setting name="PRINTERNAME" serializeAs="String">

    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
Sunday, October 31, 2021
answered 1 Month ago

As I mentioned in "How do I add files without dots in them (all extension-less files) to the gitignore file?", there is one rule to remember with .gitignore:

It is not possible to re-include a file if a parent directory of that file is excluded. ()
(: unless certain conditions are met in git 2.7+)

That means, when you exclude everything ('*'), you have to white-list folders ('/**/'), before being able to white-list files.

# Ignore everything

# Exceptions

The OP LastSecondsToLive actually took a simpler approach:

I created a commit with bundle/vim-airline/autoload/airline/themes/kalisi.vim then I switched my .gitignore back to:* !.gitinore !init.vim to ignore everything, but since bundle/vim-airline/autoload/airline/themes/kalisi.vim is already tracked, changes will get tracked in the future.

Saturday, December 4, 2021
answered 2 Days ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :