So is anybody successfully versioning their homedir with git? And do they have
any advice? I have just begun doing
it, and am still working out the process. I'm not versioning everything in my
homedir, I leave out music, photos,
videos and the like, and email, and I only version certain config files. But
most of the content I create in my
homedir, I want to version.
Git has some advantages over subversion. It doesn't depend on a centralised
repository. Although you'll probably want
to use one anyway, you don't necessarily lose anything if it goes down. You get
a good distributed backup of your
history, not just your current working tree. I particularly like that you can
just burn the .git folder from any of
your machines to a CD or DVD, verify it with git-fsck, and have a portable
backup copy that way. The repositories are
pretty small. It can detect any file corruption with cryptographic checks. You
can do commits and checkouts and
inspect history offline. Git can also run over a normal SSH connection, you
don't need any special git daemon.
Some people on the git irc channel are very against this idea. They think
you're crazy, will outright tell you
not to do it, and even threaten to stop speaking to you if you continue doing
it. Their reasoning seems to be
that you're not using git for what it was intended for, and therefore you
should find a tool that was primarily
designed for your use case. No such tool exists as far as I know, however.
There are also a number of people in the
git irc channel who do use git to version their homedir, and they are
reassuring about it.
Here's a few things I've learned:
* Don't make the git repository directly in your homedir. You don't want git
operating on 'live' config files, as
this isn't what git was designed for, and who knows what might happen. If git
dumps some merge conflicts into a
config file while the file is in use, you could break your system. Also if you
do this, then you have to abuse the
gitignore file a lot to get git to ignore everything that you're not
versioning. It's safer, if a little less
convenient, to create a git directory in your homedir and place the repository
in that directory. Then you place any
files you want to version into the git folder, and anything left outside of
this folder is not versioned and won't be
touched by git.
For config files that have to be located in your homedir you can manually copy
them in and out of your git folder, or
have "keep" and "install" scripts to do this. This should work okay for
critical config files that don't change
frequently, such as .bashrc or .muttrc. If they're non-critical and change
often it might be inconvenient, I think
you could instead replace such config files with links into your git folder. By
non-critical, I mean you could stand
this config file getting broken for a while, until you get round to fixing it,
if git does something you didn't
expect. Browser bookmarks might be a good example of a non-critical config file
(worst-case scenario: the browser
won't start, use another browser for now).
* Git doesn't track file metadata. If you care about this, I think you can
script around it. Git supports executing
custom scripts as pre-commit and post-checkout hooks. I think you could have a
pre-commit script that reads file
metadata and stores it somewhere inside the git repository, either in the
content of the files themselves, or in a
central metadata file. A post-checkout script could then read this stored data
and reset it. Once they're setup you
don't need to think about these scripts, just use git normally.
For example one of the things I keep is a pyblosxom blog, which is a collection
of text files whose mtime is
important. A pre-commit script reads the mtimes and stores them in a special
line in each of the text files
themselves, and a post-checkout script resets the mtimes to the timestamps
stored in the files. I also have config
files whose permissions are important, and this approach might not work as well
because they don't necessarily all
have the same syntax for having a line that is commented out. The post-checkout
script could probably be modified to
remove the metadata stamp from the file content, after reseting the
permissions. I'm not sure if this approach would
work for binary files, but I don't think I'll need it to.
Does anyone have scripts like this already?
* Never push to a non-bare repository, it gets confusing. If you're going to
setup a svn-like architecture where you
have one always-on central machine that all the others pull from and push to,
the repository on this machine must be
a "bare" repository that has no working copy. If you also need a working copy
on that machine, then you have to have
two repositories on that machine.
Well, that's about all I've learned, and I think it outlines a safe way to use
git to version those parts of your
homedir that you care about. Any thoughts?
vcs-home mailing list