Keeping your dotfiles in git

[chombee at lavabit.com]

I was doing this briefly in the past (and spoke about it on this list),
but the system I setup was too awkward and it soon got left behind. Now
I'm revisiting the idea, and I want to do it in as simple and convenient a
way as possible. For one thing, I'm planning on using GitHub as the
central server to keep my dotfiles, as lots of people are doing. But also,
I've been looking at the strategies people use and trying to distill the
simplest possible approach.

Google and you can find lots of people who keep their dotfiles in a git
repository. Usually they create a directory such as ~/dotfiles/ and they
move all the dotfiles they want to track into that directory, and create
the git repository in that directory. Then they have a script of some kind
(I've seen scripts in half a dozen languages for this) that creates
symlinks from the root of their homedir into their dotfiles directory,
e.g. linking ~/.muttrc/ to ~/dotfiles/muttrc/.

This seems pretty simple to me, although I don't see why a script is
necessary to create the symlinks. First, when the files in your dotfiles
directory are symlinked into your homedir, then you can simply edit the
files as if they were in your homedir, e.g. `nano ~/.muttrc`, and the
changes you make will show up when you do `git status` in your dotfiles
directory, that's convenient. Second, to create all the symlinks you only
need a simple command not a script: `ln -s ~/dotfiles/* ~/`.

I'm not entirely clear on why, in the examples I've seen, the -s option is
used to create symbolic links instead of just using hard links.

Also, I fail to see the point in having a dotfiles directory. It might
make it easy to break things up into generic dotfiles that apply to all
machines that you use and go in the dotfiles directory, and dotfiles that
are only used on particular machines and go in various
dotfiles-machinename directories. But aside from that, why not just create
the git repository directly in your homedir? Give it a .gitignore file
that ignores everything (contains one line with just a *), then add to the
repo only the files you want to version with commands like `git add -f
..muttrc`.

What about the permissions of your dotfiles? Git does not track file
permissions, except for the executable bit, so people often create scripts
to somehow store and restore the permissions of all the files. But I don't
see that this is a problem. Files created by git will have permissions
according to your UMASK environment variable, on my system they will be
readable by everyone, writable only by you, and executable by no one.
Files that you have made executable and committed into the repo will
maintain their executable bits when created or overwritten by git, but you
shouldnt find yourself using this feature if you're just tracking
dotfiles.

So that means that your dotfiles _will be readable by anyone_, if your
UMASK is the same as mine. If you don't want that, then you should just
change your UMASK. But it seems to me that there's nothing wrong with them
being readable. Lots of people even share their dotfiles now, on GitHub,
for example. As long as, obviously, you don't put passwords or other
private information into any of the dotfiles that you are tracking. This
shouldn't be too much of an inconvenience. If I want to track my .muttrc,
for example, and keep it in a public repo on GitHub, I think I'd be
perfectly happy to put my imap and smtp servers and usernames in there,
but just omit the password. (Which is what I do anyway, I don't want to
store passwords in files on my machine and then have to worry about the
machine being secure.) The only problem I can think of is that putting my
email address in a config file such as muttrc then committing it to a
pulbic GitHub repository might make it available to spammers.