ok -- after 2nd thought about your post few more questions, so that I
don't waste time implementing what you might have done already and then
discarded due to
> that just turned out really ugly and I
> had some problems with it.

When you talked about symlinks, I guess you were talking about files such as 
.bashrc, .mrconfig etc.
What problem I would encounter if I decide to go with not detached git
repository for mr (and zsh, bash, etc), but rather checkout needed ones
(non bare) under ~/.etc then

variant 1:

in the main git repository for the
account (i.e. ~/.git) I add symlinks:

.bashrc -> .etc/bash/.bashrc
.mrconfig -> .etc/mr/.mrconfig 

which I commit and push in the 'account' repository, common for all the
boxes. then all configs relevant to bash stay within bash repository
(same for mr)

such approach seems not to punish modularity much since we are talking
only about top-level hooks (links) and there should be not much of
those... and they should be common across the boxes... if module is not
there, link is hanging, then probably that module is not needed, ie not
used, thus no harm.

variant 2:

Alternative approach to completely eliminate hit on modularity
would be just to call 

ln -sf .etc/bash/.bashrc ~/

in a checkout command within mr config. So, such link would be
automagically created only if bash is requested to be on this box. And
do not have ~/.git at all -- basic common configs could reside under
~/.etc/base and be symlinked on checkout with
ln -sf .etc/base/.* ~/ ; rm ~/.git 

Such approach would (if I see it right) eliminate problem of custom
gitignores since actual ~/ will not be under VCS itself, and configs are
in modules under ~/.etc, thus there will be no noise on git
status. Also there would be no need to redefine GIT.* variables to
push changes.

where is the catch? ;-)

> This brings me to account-specific branches: I opted against them
> and instead made my configuration global so that it applies
> everywhere. This is much more straight forward than remembering to
> cherry-pick local changes into the central config and then not to
> forget to merge the central config into all local branches.

well -- changes from the central config could again be done
automagically on update command in mr, right?

=------------------------------   /v\  ----------------------------=
Keep in touch                    // \\     (yoh@|www.)onerussian.com
Yaroslav Halchenko              /(   )\               ICQ#: 60653192
                   Linux User    ^^-^^    [175555]

Attachment: signature.asc
Description: Digital signature

vcs-home mailing list

Reply via email to