Split configuration files in "static" and "dynamic" to improve a "dotfiles" repo

[TvE]

I am in the process of making a "dotfiles" repo for my Windows setup (as I have already done for my *nix setup) - a bare git repo in $HOME where I add the "dotfiles" / configuration files.

One isue I have is that the wincmd.ini configuration file is a mix of "static" configuration and "dynamic" usage data.
The static data is what I want in my repo, but not the dynamic data.

EG.: The [Configuration], [Lister] & [layout] sections describe the configuration of TC, what I call "static" - how the app is setup.
But then the [left], [right], [Lefthistory] & [RightHistory] sections are what I call "dynamic usage data", the data that's derived from the actual usage on the given PC.

So if I add wincmd.ini to my repo I'll have to only commit part of the file (omitting all the usage derived data), which is a lot of extra work.

Ideally I would expect that file to be split in to two files thus allowing me to only add the "static" one to the repo and ignore the other.

I know this is would be a fundamental change, so any suggestions for how to mitigate this design (unless it can be changed) are most welcome.


NB.: My research shows that there are a lot more people using dotfile repos than windows-config repos, which is strange as having your configuration under source control is a good thing (and helps setting up new PC's much faster...

[Gral]

You can redirect sections of WINCMD.INI.
From HELP

Using multiple ini files

There are two options which allow to redirect one or more section from wincmd.ini to other files, e.g. to make the main wincmd.ini read only. It's also possible to quickly delete volatile data like directory and command line history by putting them in a separate file, which can then be deleted regularly.

1. Global option in section [Configuration]:
AlternateUserIni=<somename.ini>
If present in section [Configuration], it will redirect storing of all user-changeable sections to an alternate ini file (in this example, somename.ini), except for the following sections: [Configuration], [Layout], [Packer], [Confirmation], [Extensions], [Associations], [Shortcuts], [ShortcutsWin], [PackerPlugins], [FileSystemPlugins], [ListerPlugins], [ContentPlugins].

2. All sections can be redirected individually:
In each section, an entry
RedirectSection=
can be added to change the default behaviour. It will allow to redirect (or not) this section to another ini file:
Possible values:
0: no redirect even if the section would be redirected by AlternateUserIni
1: redirect to ini file defined via AlternateUserIni=<alternate ini file.ini>
<ininame.ini>: redirect to that specific ini

Note:
When RedirectSection is placed in the [Configuration] section, all variables of that section will be redirected, except for AlternateUserIni and UseIniInProgramDir, which will always be read from the main ini file.

[petermad]

2TvE

See:
viewtopic.php?p=405773#p405773
viewtopic.php?p=176440#p176440

[TvE]

@gral & @petermad
AWSOME!!! - that's just what I need (and of course there's already a built-in mechanism for stuff like this in TC). The more I use it the more I like it