Using GNU Stow to manage dotfiles (2013) | Hacker News Reader

Using GNU Stow to manage dotfiles (2013)

brandon.invergo.net

84 pointspmoriarty24 comments

I'm a happy follower of https://legacy-developer.atlassian.com/blog/2016/02/best-way.... Just a plain Git repository in $HOME, no other tools required. This makes it instantly portable to any machine (with git).

This is what vcsh does, but wrapped up nicely.

https://github.com/RichiH/vcsh

Me too! My only question is how can I use tig or SourceTree with this setup.

What's the advantage of that? It looks like a lot of effort, especially each time you add it to a new pc.

It's not a lot of effort to add it to a new machine. It goes something like:

  git clone --bare https://example.com/myconfig.git $HOME/.myconfig
  echo "alias myconfig='git --git-dir=$HOME/.myconfig/ --work-tree=$HOME'" >> $HOME/.bashrc
  source $HOME/.bashrc
  myconfig checkout

...and it's done. Getting stow on a machine that doesn't have it is probably more work.

I can definitely attest that this is very easy, and best of all it's just a git repo, so there's no special tooling required. The process was seamless when I upgraded my MacBook.

With that said, i did forget the commands, and had to lookup the article. I knew how it worked, a sort of redirected git repo usable from anywhere, and used with an alternate command, but I just didn't remember the commands offhand.

The nice thing is too, is that the initial setup of things like the "myconfig" command (I use `dot`) only requires being setup once, even after switching machines. Since a new machine just requires you to setup the git repo with a couple (hard to remember lol) commands, and then suddenly your `dot` command works "magically". Because of course, it's included in your dot files.

It really is magical, and shockingly simple. I've been using it for over a year now and am fully happy.

Not really. It's two commands on Linux, three on a mac. Or one, if you just put them in a script in the repo (which is how I do it, with a few extra lines to detect my environment and use the proper install option).

    ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
    brew install stow
    stow *

    apt-get install stow
    stow -v *

I think having to have that special git alias just bugs me as being a bit unnecessarily complex, but different strokes for different folks I suppose.

FWIW I don't actually use stow, I just wrote a simple Python script to do it[0]. It doesn't handle deleting things but it just means I don't have to mess about having a special non-standard git repo in $HOME, I can just treat my dotfiles like any other git project I have.

I've starting just using GNU Make for my dotfiles [1] after struggling to choose from the abundance of dotfile managers [2] for a while. So far it's working out nicely.

[1]: https://github.com/meribold/dotfiles [2]: https://dotfiles.github.io/#general-purpose-dotfile-utilitie...

I was going to say that I do something similar with mine[1], but I looked at your makefile and saw that it's about 10x more sophisticated than mine, although I've never really had sufficient problems to warrant learning the makefile black magic. I think I'm now thankful that my dotfile needs are so basic!

1. https://github.com/davidr/dotfiles

That's a blast from the past. Should the year tag 2012 be put in the title.

I am not denying the usefulness of this post. I came across this when I was setting up stow myself.

I've been experimenting with dotbot [1] for the last little bit and it is similar to what is described here. The main difference being that the placement of the dot files is configured in a JSON/YAML file instead of a directly structure.

It doesn't have any external dependencies, unless you consider python an external dependency, but most all distros come with that built-in these days.

It's not a management system either. It's just a tool for describing where to copy things to. So if you simply choose not to use it later it's not that difficult to migrate.

[1] https://github.com/anishathalye/dotbot/

I saw the author's structure with .bashrc under the bash "app subdirectory" in stow, and thought that it would also be handy to allow your vim app subdirectory to include some bash snippets to be included in bashrc.

You can't just have multiple .bashrc files that get linked to the same ~/.bashrc destination, but you can have a ~/.bashrc.d directory and have the end of your central .bashrc source everything in that directory (in some well-defined order). then your vim app subdirectory could add shell aliases/functions for, say, invoking vimdiff in a particular way, by adding a file in ~/dotfiles/vim/.bashrc.d/vim.bashrc .

I created similar for use at work for our developers' PCs/VMs:

https://github.com/lovullo/bash-d

I've found Stow central in getting my preferred setup up and running quickly, as well as using Ansible to setup all the binaries/utils that I require.

Although I'm looking at NixOS now ...

It is a never-ending cycle, it seems. :)

Pro-tip for NixOS: NixOS won't really enforce state in /home, expecting users to save files there as normal (who wants to edit configuration.nix every time you want to save a LibreOffice file?) and to have normal backups of /home.

If you want to define your /home contents statically (because, for instance, you're running a single-user home machine and you consider your dotfiles part of your system configuration), you should instead create a /etc/users/<name> directory and set it as the home directory for your user. NixOS then allows you to define its contents as part of configuration.nix, just like anything else under /etc.

alternative: https://github.com/rycee/home-manager

I actually use this same method manually with git. I have a .theme folder in my home directory, which is a git repository, containing the directories bin and user. The bin directory houses utility and convenience scripts which are tacked on to my PATH while the user directory holds all my relevant dot files. Then, a setup script in the root .theme directory symlinks the relevant dot files from the user directory to $HOME.

The great part is that I can keep branches for each computer which share my configuration. And being that I consistently use Arch, I also employ an install script with my common packages to speed up new installations.

In the end, it shaves a good hour or so off my installation process.

Currently using stow to maintain my dotfiles too [1]. I like the separation and structure it imposes and strives to keep it simple.

Or another option with more tooling like would be something like yadm [2].

[1]: https://github.com/lutostag/dotfiles [2]: https://thelocehiliosan.github.io/yadm/

If you often switch different versions of any of your config files, confetti may suit your needs better than stow: https://github.com/aviaviavi/confetti.

If you just use stow for basic dotfiles management, confetti will also work just fine, but is less general than stow.

For those of you who like me are never quite happy with your emacs configuration or your bash prompt, I can heartily recommend stow. I used to manage my dot files with symlinks by hand; stow makes it much easier to keep all my systems configured and it's one of those admirable simple programs that does one thing well.

I use GNU Stow for dotfile management plus version control of various utilities installed locally.

> but many/most dotfiles reside at the top-level of your home directory, where it wouldn't be a good idea to initialize a VCS repository

Author hasn't heard of `ln`?

Stow is a symlink farm manager... So yes?

Reply on news.ycombinator.com