I have for many years had my entire $HOME
directory checked into subversion. This has included all my dotfiles and application profiles, many scripts, tools and hacks, my preferred basic home directory structure, not a few oddball projects and a warehouse worth of random data. This was a good thing. While it lasted.
But it's gotten out of hand. The basic checkout is the same across dozens of systems, but not all that stuff is appropriate for all my machines. It doesn't even all play nicely with different distros.
I'm in the process of cleaning house -- separating the data out where it belongs, splitting out some scripts as separate projects, fixing some broken links in stuff that should be automated, etc.
My intent is to replace subversion
with git
for the toplevel checkout of $HOME
, but I'd like to pare this down to just the things I'd like to have on ALL my systems, meaning dotfiles, a few directories and some basic custom scripts.
In reading up online a lot of people seem to be doing this using the symlink approach: clone into a subdirectory then create symlinks from $HOME
into the repository. Having had my $HOME
under full version control for over a decade, I don't like the idea of this approach and I can't figure out why people seem so averse to the straight checkout method. Are there pitfalls I need to know about specific to git
as a top level checkout for $HOME
?
P.S. Partly as an exercise in good coding, I'm also planning on making my root checkout public on GitHub. It's scary how much security sensitive information I've allowed to collect in files that ought to be sharable without a second thought! WiFi password, un-passphrased RSA keys, etc. Eeek!
git
will change the permissions of your files to644
after checkout which is bad for things like private ssh keys. howeveretckeeper
is a solution for using git with permissions for /etc/.zshrc
,.vimrc
and similar things without having to sanitize them first!