(Update 2012-03-02: see Eli’s other method in the comments)
You would think that after using Unix for this long (over 20 years), I would have finally kept my ‘dotfiles’ in order. Not so. I just kept copying or re-writing them as I moved from machine to machine.
No more. After seeing people on github demonstrating how to get their dotfiles house in order, it seemed like the right time. This was an easier choice now than ever before because git has become as prevalent as ‘ls’. It is so fast and flexible. So I took the plunge.
I took a look at a bunch of blogs about this (probably more than I needed to). The two I seriously looked at are here: the ‘ryanb’ dotfiles technique and the ‘rtomayko’ dotfiles. Both were simple. Other people on the net had these extra tools built to handle the problem. Others kept their entire home dir in version control… as in all their music and photos! I respect their work, but this puts quite a bit of stress on the rcs system.
I used the ‘ryanb’ approach. Essentially, you do a git pull on a new machine, run a ‘rake install’ so the files properly setup symlinks. Done.
I used it today and I was pleased to have all my aliases and editor tweaks working on my new machine. I will never go back.
R.Tomaykos dotfiles are better than ryanb’s. Even if he is not using zsh.
I’m in essentially the same position — has been using git for a while (and unix for decades), yet didn’t bother to organize my dot files into a proper repository. After some looking around, I found only the two approaches listed here: either make your home a git repository, or use symlinks to the actual repository.
I dislike the first for the usual reasons: more than the problem of seeing your whole world as untracked files without setting a default, there’s a more serious problem of your home directory being an actual git repo. What if you run some git command expecting it to do something except you’re not in the right directory? Usually, this will be an error (unless you’re in a different repo), but now this is guaranteed to be a mess.
OTOH, I dislike the symlink approach for more than just the minor hassle of a one-line script that creates the symlinks… What if some program updates a file by replacing the existing one? In that situation not only will it break the link to the repo and you won’t see the change, but as an added bonus the usual careless one-liner that creates symlinks will overwrite the replaced file with the previous contents therefore evaporating the new contents. Another problem: what if you want things to work reasonably well on cygwin, where symlinks are not really visible as such to native windows programs?
So I’ve finally found a solution that takes the best of both: put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory. Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case. You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
(Apologies for the huge comment, I just found it surprising that core.worktree is not mentioned for this on the pages that I found.)
Re the symlink issues. You are right, but I’ve rarely had an issue with other programs.
Overall, I haven’t had any issues with the approach. However, I didn’t know about the core.worktree approach. I’ll refer to it in the post.
I like Eli Barzilay’s approach with $HOME as your work tree. I also use GITDIR and GITWORK_TREE to toggle whether $HOME should be treated as a git repo and am trying symlink tricks to keep things like .gitignore out of $HOME but still have it tracked and shared. Alpha-ware, may toast your files:
https://github.com/bowman/.dotfiles/tree/master/.dotfiles
Hi guys, you are reinventing the wheel here 😉 All these problems have already been solved – please see vcs-home for details. For example vcsh automates the detached git working tree approach via a plugin to mr, and I have taken a similar approach with my own plugin to mr which automates symlink management via GNU Stow.