Live data from Hacker News

Using GNU Stow to manage your dotfiles (2012)

brandon.invergo.net

41–50 of 116 posts

Re: Using GNU Stow to manage your dotfiles (2012)

#41
post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

>Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go?

Well, that's what you end up with. Stow just automates the "symlink those files part".

Re: Using GNU Stow to manage your dotfiles (2012)

#43

Earlier quoted context omitted.

> and delete it another way in another place (git rm). I use `rm` all the time in git repos... Just `git add` when it is time to stage changes.

Right, but when you unlink it from your home directory, the file still exists in the git repo. So there is a manual synchronization that must happen between the two directories.

>Right, but when you unlink it from your home directory, the file still exists in the git repo.

That's a feature.

Re: Using GNU Stow to manage your dotfiles (2012)

#44
post #43

Earlier quoted context omitted.

Right, but when you unlink it from your home directory, the file still exists in the git repo. So there is a manual synchronization that must happen between the two directories.

> Right, but when you unlink it from your home directory, the file still exists in the git repo. That's a feature.

Not when you are looking for a workflow to make dealing with dotfiles faster and more painless. With the current (symlink based) setup, there is a hidden state you must hold in your head or else carefully inspect: the discrepancy between your git repo and your home directory. Maybe you forgot to link a dotfile, and that’s why your latest configuration doesn’t work. Ditto for unlinking a dotfile.

Re: Using GNU Stow to manage your dotfiles (2012)

#45
post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

Yeah, I set it up with the Atlassian tutorial, https://www.atlassian.com/git/tutorials/dotfiles, and store it in a git repo in Keybase.io

Re: Using GNU Stow to manage your dotfiles (2012)

#46
post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

Call me old fashioned, but I remember using stow in 2003/2004, about a year before git existed.

Yes though, use a repo for sync, but stow takes care of at linking your dot files in the right place.

Re: Using GNU Stow to manage your dotfiles (2012)

#48
post #6

I use this technique, based on a bare git repo https://www.atlassian.com/git/tutorials/dotfiles Works quite well ... but I'm really, really ready for a rebuild of how Linux systems are built. I hope systemd-homed will deliver. Imagine you could ssh into a machine with a flag that forwards your local config. Or even your local bin.

You mean what we had with project Athena for decades? Or NFS mounted homework? Or plan 9?

> Or NFS mounted homework?

I would not wish this pain on others. It works great when your systems are homogenous. It rapidly becomes a pain when you need to make customizations that only apply in a particular network, or on hosts with a particular OS version, etc.

My bashrc has basically just become a monstrosity to control what files get sourced for this particular host. Answering why a particular env car is set to what it is ends with me trying to trace what files get loaded, what they set, and the order they get loaded in.

Much more painful than separating the concerns and having Ansible template out my bashrc.

Re: Using GNU Stow to manage your dotfiles (2012)

#49
I'm very happy with yadm (https://yadm.io/) – it's a thin wrapper around git that adds things like alternate and templated files to use different versions of a file or to switch out part of a config for different systems and built-in support for secrets (not using the latter myself, but it's there)

Re: Using GNU Stow to manage your dotfiles (2012)

#50
post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

Not sure if Stow fixes these, but here are some problems I've had with that setup: 1. If you want to delete a file, you have to delete it (rm) in one place and delete it another way in another place (git rm). 2. Adding a new file in-situ (in the home directory) requires some finessing to get it back into the git repo and symlinked properly. 3. No easy way to apply a rename operation. 4. After changing the checked out…

If all your configs follow the XDG spec then you can turn ~/.config itself into the repo,and then use .gitignore as a whitelist:

    /*
    !git/config
    !tmux/tmux.conf
I do this and clone my repo directly to .config on a new machine. The only hold out was tmux but that's solved by installing or compiling one of the recent versions released this year (3b/3c). I'll still use manual symlinks for things like bash, but they're outliers.

Works great for me.

Post reply on HN