I was doing this briefly in the past (and spoke about it on this list), but the system I setup was too awkward and it soon got left behind. Now I'm revisiting the idea, and I want to do it in as simple and convenient a way as possible. For one thing, I'm planning on using GitHub as the central server to keep my dotfiles, as lots of people are doing. But also, I've been looking at the strategies people use and trying to distill the simplest possible approach.
Google and you can find lots of people who keep their dotfiles in a git repository. Usually they create a directory such as ~/dotfiles/ and they move all the dotfiles they want to track into that directory, and create the git repository in that directory. Then they have a script of some kind (I've seen scripts in half a dozen languages for this) that creates symlinks from the root of their homedir into their dotfiles directory, e.g. linking ~/.muttrc/ to ~/dotfiles/muttrc/. This seems pretty simple to me, although I don't see why a script is necessary to create the symlinks. First, when the files in your dotfiles directory are symlinked into your homedir, then you can simply edit the files as if they were in your homedir, e.g. `nano ~/.muttrc`, and the changes you make will show up when you do `git status` in your dotfiles directory, that's convenient. Second, to create all the symlinks you only need a simple command not a script: `ln -s ~/dotfiles/* ~/`. 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. Also, I fail to see the point in having a dotfiles directory. It might make it easy to break things up into generic dotfiles that apply to all machines that you use and go in the dotfiles directory, and dotfiles that are only used on particular machines and go in various dotfiles-machinename directories. But aside from that, why not just create the git repository directly in your homedir? Give it a .gitignore file that ignores everything (contains one line with just a *), then add to the repo only the files you want to version with commands like `git add -f ..muttrc`. What about the permissions of your dotfiles? Git does not track file permissions, except for the executable bit, so people often create scripts to somehow store and restore the permissions of all the files. But I don't see that this is a problem. Files created by git will have permissions according to your UMASK environment variable, on my system they will be readable by everyone, writable only by you, and executable by no one. Files that you have made executable and committed into the repo will maintain their executable bits when created or overwritten by git, but you shouldnt find yourself using this feature if you're just tracking dotfiles. So that means that your dotfiles _will be readable by anyone_, if your UMASK is the same as mine. If you don't want that, then you should just change your UMASK. But it seems to me that there's nothing wrong with them being readable. Lots of people even share their dotfiles now, on GitHub, for example. As long as, obviously, you don't put passwords or other private information into any of the dotfiles that you are tracking. This shouldn't be too much of an inconvenience. If I want to track my .muttrc, for example, and keep it in a public repo on GitHub, I think I'd be perfectly happy to put my imap and smtp servers and usernames in there, but just omit the password. (Which is what I do anyway, I don't want to store passwords in files on my machine and then have to worry about the machine being secure.) The only problem I can think of is that putting my email address in a config file such as muttrc then committing it to a pulbic GitHub repository might make it available to spammers. _______________________________________________ vcs-home mailing list [email protected] http://lists.madduck.net/listinfo/vcs-home
