mrsetup and the rest of the toys

[Yaroslav Halchenko]

I somewhat went with variant 2 ( + per-host if needed branches).
To accomplish it, I've crafted a custom action for mr: git_clone_link
[1], the job of which is to 

1. clone a repository 

2. if _links directory is present, create symlinks in the home directory
leading to the original files pointed at _links/*. If no _links, then
all files/directories under the root directory of the repository are
symlinked from home

3. verify if there is an account-specific branch, and if there is --
check it out (instead of master).

Example:

[.etc/vim]
checkout = git_clone_link 'ssh://git.onerussian.com/~/git/pub/etc/vim.git' vim

and at the end with the rest of few other configurations which I moved to git
already I have

$> ls -ld .* | grep '\.etc'
  0 drwx------   6 yoh  yoh      47 2008-07-22 16:42 .etc/
  0 lrwxrwxrwx   1 yoh  yoh      17 2008-07-22 15:33 .gnupg -> .etc/gnupg/.gnupg/
  0 lrwxrwxrwx   1 yoh  yoh      11 2008-07-22 16:41 .mr -> .etc/mr/.mr/
  0 lrwxrwxrwx   1 yoh  yoh      17 2008-07-22 16:41 .mrconfig -> .etc/mr/.mrconfig
  0 lrwxrwxrwx   1 yoh  yoh      13 2008-07-22 16:03 .ssh -> .etc/ssh/.ssh/
  0 lrwxrwxrwx   1 yoh  yoh      13 2008-07-22 15:33 .vim -> .etc/vim/.vim/
  0 lrwxrwxrwx   1 yoh  yoh      22 2008-07-22 15:33 .vimrc -> .etc/vim/_links/.vimrc


pros:

 modularity is preserved quite well imho

 flexibility among the hosts is available through branches per each module

 you can easily perform git operations (fetch, status, but not pull) within
each symlinked directory (e.g. ~/.vim) directly. git seems to be good enough to
don't rely on full path but rather to use .. to figure out top directory, thus
it works just fine. pull is somewhat broken in that regard. And sure thing you
can simply operate in full power under ~/.etc/WHATEVER
 
cons:

 symlinks may be ?? although they seems to be easy to fix if anything goes
wrong (like you remove .ssh), and also it provides visibility of what
files/directories are kept within VCS (whatever has no link to .etc/ is not
under VCS)


(in .vim there is no obvious need for _links/ but I left it as an
example). Public portions of those configurations are available
at [2].

Now, to populate home directory I slightly changed madduck's mrsetup and
now it could be found at [3]


[1] http://git.onerussian.com/?p=code/mr.git;a=blob;f=lib/git-link;h=db05408c41445d9a0824c07c5ef17d442b0f2548;hb=2ae6f6892308c33ee11f1f3f3b37543825519e63
[2] http://git.onerussian.com/
[3] http://git.onerussian.com/?p=etc/mrsetup.git;a=summary

On Thu, 17 Jul 2008, Yaroslav Halchenko wrote:

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