There was a recent post by Martin Meredith asking about dotfile management.
This inspired me to put together a simple hack which allows several operations to be carried out:
- dotfile-manager update [directory]
Update the contents of the named directory to the most recent version, via "hg pull" or HTTP fetch.
This could be trivially updated to allow git/subversion/CVS to be used instead.
(directory defaults to ~/.dotfiles/ if not specified.)
- dotfile-manager link [directory]
For each file in the named directory link _foo to ~/.foo.
(directory defaults to ~/.dotfiles/ if not specified.)
e.g. directory/_screenrc will be linked to from ~/.screenrc. But hostnames count too! So you can create directory/_screenrc.gold and that will be the target of ~/.screenrc on the host gold.my.flat
- dotfile-manager tidy
This removes any dangling ~/.* symlinks.
- dotfile-manager report
Report on any file ~/.* which isn't a symlink - those files might be added in the future.
Right now that lets me update my own dotfiles via:
dotfile-manager update ~/.dotfiles dotfile-manager update ~/.dotfiles-private dotfile-manager link ~/.dotfiles dotfile-manager link ~/.dotfiles-private
It could be updated a little more, but it already supports profiles - if you assume "profile" means "input directory".
To be honest it probably needs to be perlified, rather than being hoky shell script. But otherwise I can see it being useful - much more so than my existing solution which is ~/.dotfiles/fixup.sh inside my dotfiles repository.
ObFilm: Forever Knight
I agree that having names starting with a dot inside ~/.dotfiles would be redundant and inconvenient. But why have a prefix at all? Why ~/.dotfiles/_screenrc instead of ~/.dotfiles/screenrc?
I guess I just thought of replacing the "." with something else to make working with the repository more straightforward - rather than removing it.
We'll blame it on historical crazyness!
Why keep dotfiles in ~/.dotfiles rather than ~ ? I check out my home directory's git repository directly in ~ .
Having the files be in a directory is a historical artifact because previously I was storing them under CVS.
Still most revision control systems expect projects to be inside a single prefix - and I like that system myself because it allows me to easily install on a different host via rsync / scp.
Liking this, wish it'd sent me a pingback!
I'll have a look at your thing tomorrow, it looks pretty neat at first sight, and could probably be tidied up (and probably pythonised and made nicer) and then packaged :D