Why not just have a git repo working copy in your $HOME directory? That way you can avoid any symlinking mess. The actual dotfiles are the ones from the working copy.
I used to do symlinking but found the working copy in $HOME approach much better.
What .git mess? I think the working copy in $HOME is cleaner as you don't have symlinks everywhere. The only new addition to your home folder is a '.git' directory. This is no different than the myriad of other hidden directories already there.
That could work, but where would the .git/ directory be? If you have in $HOME/.git you are inviting disaster with an errant 'git clean...' command. If not you need to deal with managing the options/environment to make the git commands work (though that could be scripted).
I'm curious about this too since something dead simple (and reasonably idiot-proof) would be useful to me as well.
Do you intend to never use 'git clean -x...' anywhere in your home directory? when you run 'git <command>' git will go upward through the directory tree until it finds a .git directory. If you intend to run 'git clean -fx' in ~/foo/project/src but are instead in ~/foo/tmp/src/ (which is not a git repository) it will run that clean against all of ~/ instead.
Having ~/dotfiles/.git and aliasing a command that sets GIT_DIR=~/dotfiles/.git and GIT_WORKDIR appropriately would be safer.
great suggestion. I added an alias of 'dotfiles' to my environment which prefixes the git command with the GIT_DIR and GIT_WORKDIR described above. Now when I want to work with my dotfiles I just use that command instead of 'git' directly.
I understand the .git search path, but I almost never use `git clean` in my projects (usually just `git reset --hard` or `make clean`), so I've never been too worried.
But your solution is definitely safer -- although I think you meant GIT_WORK_TREE, not GIT_WORKDIR, right? I'm going to switch. Thanks!
This is still risky if your ~/.git had uncommitted changes. I'll admit to being a little paranoid but I spent enough time on the #git irc channel to learn that any advice that is potentially dangerous will _always_ be used in the dangerous fashion, often without knowledge of the risks.
> although I think you meant GIT_WORK_TREE, not GIT_WORKDIR, right?
Fails to delete symlinks to removed dotfiles. Doesn't support splitting dotfiles amoung multiple repositories.
I feel that the right solution to this is going to be vcsh.https://github.com/RichiH/vcsh No symlinks to dotfiles, all the files live in $HOME, but vcsh can be used to switch between accessing different git repositories that contain different of the dotfiles. http://vcs-home.branchable.com/ has more.
Sure it supports splitting dotfiles among multiple repositories. Just create multiple repositories and change the path in the post-commit hook. Deleting symlinks would be nice, but I'm not sure it's worth the complexity implementing it would add.
vcsh sounds like a neat system if you need to have multiple repositories with the same working directory, but I don't understand the advantages of this for managing your dotfiles. My eyes glazed over when reading about the proposed system in section 3.2 of the README.
This really is super-simple, and I like that. However, it doesn't handle configuration files that don't go directly in your home directory, such as $HOME/.ssh/config. I wrote something a few weeks ago which does that while remaining conceptually very simple. You can get it at
https://github.com/sciurus/dotfile_management
I want to be able to manage other config files that aren't in my home directory at all. Some of them are even owned by root: httpd-vhosts.conf, /etc/hosts, php.ini... any good solution for that? I'm willing for it to be complex if it works.
Manage in what sense? If you're trying to sync. between multiple machines, one approach is to check in the /etc files in your home dir and symlink. Or are you looking for something else?
19 comments
[ 2.9 ms ] story [ 45.0 ms ] threadI used to do symlinking but found the working copy in $HOME approach much better.
I'm curious about this too since something dead simple (and reasonably idiot-proof) would be useful to me as well.
Having ~/dotfiles/.git and aliasing a command that sets GIT_DIR=~/dotfiles/.git and GIT_WORKDIR appropriately would be safer.
But your solution is definitely safer -- although I think you meant GIT_WORK_TREE, not GIT_WORKDIR, right? I'm going to switch. Thanks!
EDIT: Working nicely :) https://github.com/nixme/dotfiles/commit/64486fe25e6750567a0...
This is still risky if your ~/.git had uncommitted changes. I'll admit to being a little paranoid but I spent enough time on the #git irc channel to learn that any advice that is potentially dangerous will _always_ be used in the dangerous fashion, often without knowledge of the risks. > although I think you meant GIT_WORK_TREE, not GIT_WORKDIR, right?
Yeah, brain cramp on that one, sorry.
I feel that the right solution to this is going to be vcsh.https://github.com/RichiH/vcsh No symlinks to dotfiles, all the files live in $HOME, but vcsh can be used to switch between accessing different git repositories that contain different of the dotfiles. http://vcs-home.branchable.com/ has more.
(Also, rake? yadr? vcsh is a posix shell script.)
vcsh sounds like a neat system if you need to have multiple repositories with the same working directory, but I don't understand the advantages of this for managing your dotfiles. My eyes glazed over when reading about the proposed system in section 3.2 of the README.