To install, you need to perform following steps:
Clone repository to a stable place on your box
For now, I'm going to assume it's local/mydots
$ cd local/mydots
Move (and merge if needed) your existing configs to dotfiles folder. Remove the dot from name, e.g.:
$ mv ~/.gnucash dotfiles/gnucash
If your configs live under ~/.config
folder, put them under a similar
folder under dotfiles:
$ mv ~/.config/dunst dotfiles/config/dunst
Since unlike the "classic" scheme where dotfiles live right under $HOME, with ".config", you don't want to share whole config, so you need to tell dottum to look for link targets on deeper level. This is done by adding entry to file "dotfiles/dotvault/subvaults":
$ mkdir dotfiles/dotvault
$ echo "config" >> dotfiles/dotvault/subvaults
This will caulse dottum to look inside the config
sub-folder
rather than treat it as whole and create link at ~/.config
. Note that
you can do this at any depth, for example, in vault that keeps only host
specific files, you can do
$ echo "config/myapp/hosts" >> dotfiles/dotvault/subvaults
and have dottum look for items under config/myapp/hosts
and link them
under ~/.config/myapp/hosts
, eg. ~/.config/myapp/hosts/foo ->
~/local/mydots/dotfiles/config/myapp/foo
Run dottum script with single argument: path to dotfiles folder (or how you named it), e.g.:
$ dottum ~/local/mydots/dotfiles
The script will create links back in your $HOME
, uless they (or real
files) did already exist, in which case it will only warn you. This
makes it easy to exclude some of your applications from some of your
machines: just skip step 2 for them.
Pro tip: Notice how the dottum script discovers your .config/
-bound
files such as dunst.
The path you pointed to is "path/to/dotfiles", so this will be regarded as "base path" of your config pool.
Any members of the base directory will be prefixed with single dot and symlinked directly to your home--just as the ancient tradition dictates.
If the "base path" has neighbor called the same but with suffix
.config
, i.e. path/to/dotfiles.config
, it will symlink all
present members to ~/.config
path--just as XDG convention
uses in its most common version.
The case is similar for .local/share
files; here you'll just need
to go one step deeper: files that should be linked to ~/.local/share
should be in dotfiles.local/share
.
Although similar technique could be used for bash, I prefer to have defaults specified by distro. Therefore I use other technique:
Instead of step 2 above, move/merge your specific ~/.bashrc changes to either one of these, or preferably, split them as needed:
dotfiles/bash/main.bashrc
dotfiles/bash/user/<your-username>.bashrc
dotfiles/bash/host/<your-hostname>.bashrc
dotfiles/bash/post.bashrc
Then, replace your ~/.bashrc with your default distro's one, commonly found
in /etc/skel/.bashrc, and use dotfiles/bash/setup
to patch it:
$ cp /etc/skel/.bashrc ~/
$ local/mydots/dotfiles/bash/setup
From that point on, .bashrc
will source appropriate fies for you, so do not
make any changes to your local .bashrc
, unless you really want them to be
local, i.e. private only.
If you want to keep default vim-ish behavior and have all local config in ~/.vimrc, you can use above generic steps. However, if you want to have rather more sophisticated model, and for example use my vim configuration as a starting point, do this instead of step 2:
Merge your local ~/.vimrc into dotfiles/vim/vimrc
Create a symlink to ~/.vim/vimrc:
$ cd
$ ln -s local/mydots/dotfiles/vim/vimrc .vimrc
You could actually have your .vimrc symlink point right to local/mydots/... I find this more flexible, though.
Additionally, if you want to use perlcritic.vim, you need to:
install Perl::Critic (from CPAN)
put bin/perlcritic_vim to your PATH
Note: For most of config I have shared, you will need at least git 1.8. Without it, things will not work, and you might even end up with broken git!
However, if you only want to use the sharing/splitting mechanism, 1.7 should be OK. No warranties, though.
The pricnicple is the same as in bash section above: a new folder is created, local config is split into parts per user/host or global one, and original file becomes just a crossroads into these.
Except that since git does not support expansion in config paths, the file must be created by a script. So what you want to do is the same as for bash above, except that instead of applying patch to your .gitconfig, you simply delete it and run dotfiles/git/setup.
If you have a local changes that you don't want to share, you can either put them into the re-created ~.gitconfig, or (as I prefer) in dotfiles/git/private/gitconfig