Re: How to manage parameter files and code separately using git?

From: Junio C Hamano <gitster@pobox.com>
Date: May 1, 2010, 17:18 UTC
Message-ID: <7vmxwj5ym8.fsf@alter.siamese.dyndns.org>
In-Reply-To: <op.vb0195s1a8ed4e@dellschleppa>

"Tilo Schwarz" <tilo@tilo-schwarz.de> writes:

Show 10 quoted lines

> I use git for "normal" c coding, i.e. having branches like master, test,  
> foo, etc. Built are executables (Linux), which need parameter text files  
> to work. What I did up to now was to check in the parameter files in the  
> same way I check in the code: when I change a parameter file, I do a  
> commit on it, this way I always have a history of my parameter files.
>
> This has one drawback: If I check out an older version, I also get the old  
> parameter file, which is not what I want, because the parameters are  
> determined by hardware settings. I.e., I would like to checkout an old  
> commit, but still have the last version of the parameter file.

This design constraint makes the issue not a version control problem but more of a software engineering problem. The changes to your parameter file have its own history (e.g. you upgraded your machine last week with different hardware---the software didn't change but the parameter has to) and the history is largely independent of the software that reads the file. In that sense, you should _never_ tie its history with the history of your software.

At the same time, the history of the parameter file is not completely independent of that of the software. You may have added a new feature and code to read a new setting in the parameter file today and older parameter file would not have a setting for that variable.

The method I used in my day-job project is something like this:

 - Include a "config.sample" file and track it in the history of the
   source code; the values it gives to the variables are the same as the
   default ones.  This file mostly serves as a documentation.

 - Design your parameter mechanism in a way that:

   - a parameter file can include another;

   - an unrecognized parameter setting is ignored;

   - a variable definition that happens later overrides an earlier
     definition.

 - Have a real parameter file that is _not_ tracked in the history of the
   source code.  Have it include parameter.sample and then define machine
   specific settings after that to override.

It is only required for the "real" parameter file not to be tracked in the history of the source code---it is perfectly fine to track it in a separate history. The easiest way to do this would be to keep a parameter working tree next door, and "ln -s ../params/config config" in the working tree for the source code. You could keep this symlink tracked in the source history, but you do not have to.

You will try to read from ./config, which will include ./config.sample in order to read the default, and then read the customized setting that appear later in ./config. Because of the symlink, you will actually be reading from ../params/config next door.