* [EMAIL PROTECTED] <[EMAIL PROTECTED]> [2008-08-27 00:00]:
> I fail to see the point in having a dotfiles directory. […] Why
> not just create the git repository directly in your homedir?
For Subversion there might not be a point. For git and most other
DVCS, there is: since it tracks trees and not files, unrelated
sets of files should go into separate repositories.
So you then end up with one repo for all the vim dotfiles,
another with your muttrc, and so on, each of which needs to be
a separate directory. Putting those all directly into $HOME is
Also, if you want to get fancy, you can use a script wrapper
around `git pull` that turns the symlinks into copies before
pulling and deletes the copies and recreates the symlinks
afterwards – but only if the merge succeeded. That way, your
apps and tools never encounter config files with conflict
markers in them.
> Second, to create all the symlinks you only need a simple
> command not a script: `ln -s ~/dotfiles/* ~/`.
It’s nice not to have leading dots in the filenames of dotfiles
within the repository, so the command has to be more complex than
Also, when you split out sets of dotfiles into different repos,
you end up with things like `~/dotfiles/vim/vimrc` which needs to
be symlinked, but where `~/dotfiles/vim` itself also corresponds
to `~/.vim` instead of having a `.vim` subdirectory (because,
again, it’s nicer not to have to work around dotted filenames
when working in the repo).
All this makes the linking complex enough that you don’t want to
type it by hand over and over.
> 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.
You can’t hardlink directories so it’s a moot point either way,
but with symlinks you can also do an `ls -l` and immediately see
which files are under version control: they are symlinked
somewhere below `~/dotfiles/`.
Aristotle Pagaltzis // <http://plasmasturm.org/>
vcs-home mailing list