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

["Tilo Schwarz" <tilo@tilo-schwarz.de>]

On Sat, 01 May 2010 19:18:55 +0200, Junio C Hamano <gitster@pobox.com>  
wrote:

Thank you for the detailed explanation!

> 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.

Ok.

> 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.

Exactly.

> 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.

I actually did exactly that already (but forgot to mention it in my first  
mail, sorry!). The problem with this "one" config.sample is, that I need  
about three really different config files because of really different  
sensor setups on about five different computers. So when I push on a USB  
stick, walk to another computer, then pull and try to run the software -  
bummer, forgot to copy the current config file - walk back, copy ...
But maybe the solution below solves this too. Or I write a little script  
doing the push and parameter file copy.

>  - Design your parameter mechanism in a way that:
>
>    - a parameter file can include another;

Can't do that yet.

>    - an unrecognized parameter setting is ignored;

Can do.

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

Can do.

>  - 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.

Good idea.

> 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.

I see. So if I want parameter file history the only proper solution is to  
have a separate parameter file git repo, right?

> 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.

Ok, will give it a try.

-- 
Regards,

	Tilo