Forking dotfiles on github is pretty trendy. But what if you don't want a full-fledged fork of others' settings?
What if you just want to synchronize your own dotfiles, on different machines?
Then you want two repositories, not just one.
- Your dotfiles. The things you want to version and synchronize.
- Dotfile management software
- A github repository just like any other. Not forked (unless you want to develop it!)
Philosophy and goals
Dotfile repositories have to figure out what to do with the
$HOME directory. Most take one of two approaches:
- dotfiles are symlinked from the repository
- Pro: Cleaner setup. All the versioned files are in one place!
- Con: Fragile. Too easy to whack changes.
$HOMEis a repository
- Pro: Simple. Files really do live just where they seem to live.
- Con: Messy. Everything you don't version will clutter up your
- Con: Dangerous! Running
gitcommands in the wrong directory could make a mess, instead of a harmless error message
dotsync takes a third approach: A git alias with predefined options
- The dotfiles live in the HOME directory (no worries about whacking symlinks)
$HOMEis not a repository (you won't mess it up if you
gitin the wrong directory)
These commands install
dotsync to a directory called
dotsync/, under your current working directory:
git clone git://github.com/chiphogg/dotsync.git ./dotsync/install
Now that you've got a repository
- Should play nice with
$HOMEwhen it writes the
- I owe a lot to Silas Sewell's original blog post. In fact, at its core,
dotsyncis an attempt to make his approach as automatic and shareable as possible.
- Eli Barzilay's blog comment helpfully articulated some philosophical points
- For help with bash completion (once I implement it!), I'm looking to blog posts by Chris Lalancette and Robert Escriva.
- Note to self: I'll need to distinguish between
PROMPT_COMMANDto do fancy things with the