chombee chombee at
Mon Nov 26 02:33:11 CET 2007

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?

More information about the vcs-home mailing list