In the past, I already attempted to manage some of my configuration files, and failed twice:
I made it a public github repository, and added too much - creating an unmanageable mess of sometimes constantly changing files, with the few really useful ones strewn in. I also forgot that some files revealed information about SSH ports and the like. Ouch. Quickly deleted all traces of it, hopefully.
Tried a homebrew synching mechanism with symlinks, some of them to folders that contained not only the interesting config files but also caches and the like. I quickly lost sight of what is where and the process of adding files (moving the file to the backup location, creating a symlink for it) and removing files (tracing symlinks, copying back the original files…) was too complex.
So what do I actually need/want?
This still leaves me with the most important question:
Configuration files that took a while to set up, don’t change regularly, don’t depend on software or hardware versions, and are less pain to copy over and edit, than to recreate them from scratch.
Also scripts (my complete
~/bin) and other pieces of valued code.
More often than not, these files aid personal habits, like keyboard shortcuts or custom menus.
There can’t be a finite definition, and that’s why it’s so important that
Most of these requirements and musings seem to be supported by the scheme described in this article - at least theoretically. Let’s see how I can put it into practice.
git init --bare $HOME/.dotfiles alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME' dotfiles config --local status.showUntrackedFiles no
and don’t forget to:
echo "alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME'" >> $HOME/.bashrc
Now start adding some files:
dotfiles status dotfiles add .vimrc dotfiles add .bashrc # etc... dotfiles commit -m "Initial commit"
But I cannot puds these changes anywhere yet.
Unlikely the writer of the article, I don’t want to put an ssh daemon on my main machine, instead I want to have the dotfile repository on my server. How to get it there? I have some experience with a) github and b) local git repositories, but this is new. Do I need to set up a git server? It seems no, I can do it all over SSH, which is already working on all ends. This actually aids my wish for remote but private access.
Nevertheless, the official git guide recommends setting up a separate git user. Done. Setting up (the git user’s) SSH keys is a piece of cake by now. For those who don’t think so, this is the ultimate set of instructions. Now initialize a bare repository:
git@localhost:~$ mkdir dotfiles && cd dotfiles git@localhost:~/dotfiles$ git init Initialized empty Git repository in /home/git/dotfiles/.git/
But how to get the original repository on my home machine onto the server, so it becomes push- and pullable? After some trial and error, I ended up using the exact method described in this answer:
dotfiles clone --bare ~/.dotfiles /temp/path/to/dotfiles)
From there onwards, I clone the repo to another machine much like described in the next step of the article.
Back on the originating machine I can finally start pushing out changes:
dotfiles push origin master
Then to the remote machine:
So from now on, this is normal git stuff.
What about files that do not reside under my
If I try to add them to the repo I get:
dotfiles add /etc/default/grub fatal: /etc/default/grub: '/etc/default/grub' is outside repository
Simple solution: A weekly backup script I’m already using can be expanded a little to zip up the whole /etc folder - excluding my adblocking hosts file it’s just a few MBs:
date="$(date +%Y%m%d%H%M)" backup="/home/username/.local/share/etc.7z" # the 7z command will fail if this doesn't end in 7z mv "$backup" "$backup.$date" 7z a -mhe=on -x'!etc/hosts' -p"$(cat /root/etc.zip.pwd)" "$backup" /etc && rm "$backup.$date"
Since I am backing up all of this anyway with borg, I can be a little sloppy about it.
/root/etc.zip.pwd is only readable by root.
Let’s try again:
dotfiles add etc.7z # commit, push etc.
No errors. Done!
Sep 9th, 2017