Git dotfiles without the bloat (rake, yadr, make, kitchen sink) | Hacker News Reader

Git dotfiles without the bloat (rake, yadr, make, kitchen sink)

blog.piasetzki.name

10 pointsjpiasetz19 comments

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

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.

I do the same (https://github.com/nixme/dotfiles). To minimize noise, I put * in my .gitignore so only files that are 'add -f' are tracked.

It's a bit of a trade off between symlinking mess and .git mess. I just prefer a cleaner home folder. I did try it all in home for a bit.

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.

I did this for four years, but I stopped because it's too easy to miss new files with the wide gitignore it requires.

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.

With * in .gitignore, you'd have to use '-x' with 'git clean' to delete everything. That's idiot-proof enough for me.

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!

EDIT: Working nicely :) https://github.com/nixme/dotfiles/commit/64486fe25e6750567a0...

> I... usually just `git reset --hard`

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.

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.

(Also, rake? yadr? vcsh is a posix shell script.)

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.

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.

I just move those into my ~/config git directory and symlink them from there.

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?

I can't see the whole line of the code.

Fixed. It's also in the git repo.

Reply on news.ycombinator.com