Hacker News Reader

Comment by justinmk | Hacker News Reader

"dotfiles managers" are over-engineered waste of time. You only need git. Create ~/.gitignore with a single line:

git tracks modifications to your dotfiles. And on the rare occasion that you need to add a new file, just force-add it:

    git add -f ~/.foorc

If you need a script to "install" your dotfiles, you're doing it wrong.

View on HN

I fail to see how this comes with the convenience of directory-specific symbolic links, dotfile-specific backups, individual removal & replacement of dotfiles, etc etc.

I've been using stow for years to manage my dotfiles and it's never been more involved than

$ stow dotfiles/urxvt

or what have you. In fact I would say that managing a git repository is more of a waste of time and far more over-engineered for a task easily solved by a tiny binary.

Not sure what you're referring to by an 'install script', have you ever used stow?

In any case, the real answer is that you should be using whatever works best for your use case, and for me that's stow.

That does not work for me. When I try "stow foo/bar" I get this error:

  Undefined subroutine &main::error called at /usr/bin/stow line 568, <DATA> line 18.

where line 568 of /usr/bin/stow is:

  error("Slashes are not permitted in package names");

What version of stow do you have? I'm using stow 2.2.0-r2 on Gentoo Linux.

From the documentation page:

>A package directory is the root of a tree containing the installation image for a particular package. Each package directory must reside in a stow directory — e.g., the package directory /usr/local/stow/perl must reside in the stow directory /usr/local/stow. The name of a package is the name of its directory within the stow directory — e.g., perl.

https://www.gnu.org/software/stow/manual/stow.html

The article in the OP also doesn't use this format. Instead it's prefaced with a `cd` command, so you would need to do:

    cd foo; stow bar

I use xstow, which permits slashes; usually I do just cd into the dotfiles directory and stow out from there (otherwise you need to specify a target directory) but I left that part out for brevity.

I tried this but git uses ~/.git for any subdirectory of $HOME. For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository. It's easy to undo but still kind of annoying.

You can add

export GIT_CEILING_DIRECTORIES=~

to your .bashrc (or equivalent)

> For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository.

If your project has its own .git directory, no, it won't add to ~/.git.

You're right. I forgot to mention that this only happens if you haven't initiated a new git repository in the directory you're working in.

I do a variation on this where I have an alias in bash for `dit` that makes it `git --git-dir=~/.config/dit --work-tree=~` and use that to manage my dot files. Avoids a bunch of the common issues with using git directly.

I agree. I looked at quite a few dotfile managers, and all of them were overly complicated and couldn't replace my use of stow. Stow was not created as a "dotfiles manager" though, and keeping dotfiles seperate from all the other crud under ~/ is a lot cleaner in my opinion. I don't want my home directory to be a git repo either.

I do pretty much this but I have public dotfiles (on github), then an overlay for work files so I need a script to maintain those symlinks, and then work ones that I don't share with coworkers (contain private passwords).

So I have a script that manages the symlinks for multiple such repos, knows to remove the broken links as needed, and I have something I can just paste into the terminal of any machine and it'll set that box up with my public/work/private dotfiles as appropriate.

It's not perfect, but it works, just pointing out that even for relatively simple cases having a dotfile manager (or writing your own) can make sense.

I still resolve the "overlay for work files" situation manually. Would you care to share your script?

Okey, but prepere for some super-lame ad-hoc code. Also I was misremembering about it handling multiple repos, in the one place where I have >1 I just do that manually.

My .bashrc will run a bootstrap_work_dotfiles function when bash starts: https://github.com/avar/dotfiles/blob/master/.bashrc#L410

This then clones my ~/g/avar-dotfiles-work repo if I'm at work and it hasn't been cloned: https://github.com/avar/dotfiles/blob/master/.bashrc#L355

I have a "dud" function (dotfile update) function that'll update both, it basically does a git pull, re-chmods ~/.ssh/config: https://github.com/avar/dotfiles/blob/master/.bashrc#L381

And also, and what you asked for, removes any stale symlinks via this one-liner: https://github.com/avar/dotfiles/blob/master/.bashrc#L348

Basically doing a find on my ~ directory and finding any broken links pointing to the known location of the overlay repo.

I see now that there's a potential bug in it where it narrows its search in such a way that it could miss it if you add/remove new ~/.??* files. This could be solved, but I have it like that because I only ever add/remove stuff in e.g. ~/.bashrc.d/ or ~/.screenrc.d/, so this way the find takes less time to run.

Then I have a generated one-liner that I can paste into new machines that clones my dotfiles.git into ~/g/, moves the .git to ~/, then sources bashrc which bootstraps the rest.

Thanks a lot.

This seems like an astonishingly good idea. It maybe lacks features for my home computer, but would be good for throw away servers like those you get from DigitalOcean, where I systematically set up everything over and over again each time.

I did this for a while. I had to switch to stow when I got a new job that had data security requirements - I had to keep the "work" bits of my dotfiles separate from the non-work parts, and so couldn't keep everything in the same git repository. Ended up writing a set of rcs that just imported appropriate .d directories, keeping two git repos, and stowing both of them.

I don’t want to have a Git repository in my $HOME; I prefer to have it somewhere else correctly organized then symlink everything.

I manage my dotfiles in a separate git repo in ~/.dotfiles, and I have simple scripts that link and unlink everything. It's worked well for me for quite some time:

https://github.com/tgamblin/dotfiles

That's a really nice solution actually, letting git do the magic. I'm definitely gonna try it. At the moment I use a python install script that backup already existing files and set up the symlinks.

I made a script which makes that kind of thing easier to manage: https://github.com/tubbo/homer

Or take a look at vcsh and the other projects here:

http://vcs-home.branchable.com/

I've got my configs stored in a git repo at ~/configs, which contains a makefile that sets up symlinks for me.

Reply on news.ycombinator.com