1. 40

I heard about stow a couple of times before but only recently gave it a look and I was really surprised how simple it is, so I started using it.


  2. 6

    I agree, Stow is probably the simplest way for version controlling your configurations. I’ve been using it for quite some time now and I’ve used it for both my personal dotfiles and server configurations.

    1. 4

      I prefer vcsh, because it doesn’t leave symlinks scattered everywhere but instead shadows the cfg files in its repositories. It’s just tidier on the outside.

      1. 5

        I don’t understand how this is better than symlinks? Both of these solutions seem equally messy. I also don’t really see much issue with symlinks, especially when managed by Stow, but that is just a matter of taste.

        1. 3

          One very important design feature that vcsh has, is that it stores the actual repositories separately from their working trees so one can simply rm -fr $HOME/.config/vcsh/repo.d without any ill effects - your config files are still there, you “only” getting rid of their repositories’ history.

          With stow, if you remove the repository, you end up with dangling symlinks, not to mention broken environment.

          Also, vcsh is just a POSIX shell script - not that I have anything against Perl, but the latter might be outdated or not at all available on your system.

          Taking to account all of the above, vcsh seems like a leaner and cleaner solution… but that’s only IMVHO.

        2. 1

          Huh, I never heard about that before, thanks for mentioing it, looks interesting.

        3. 4

          This works fine for my purposes:

              alias homegit="GIT_DIR=~/prj/dotfiles/.git GIT_WORK_TREE=~ git"
          1. 1

            It really bugs me why this sort of solution (without some intermediate layer) doesn’t get more attention. I use alias dotfiles='git --git-dir=.dotfiles.git' myself.

          2. 3

            I use a custom bash script. What is the advantage of Stow? The advantage of my solution is that it does require to install stow. I use this on machines, where I have no root/sudo access.

            1. 3

              I used a custom bash script for a long time, but eventually switched to Stow and a custom Makefile. For me, the advantage is mostly organizational. It’s nice to install a subset of configs, have different configs depending on operating system or environment, an easy ability to remove the configs, etc. The flexibility of the --no-folding option is also nice depending on whether or not everything in a directory is managed via Git.

              There are a lot of dotfile management frameworks out there, but Stow is a very simple tool that’s ubiquitously available as a package, but also trivial to bootstrap into a local directory if you don’t have admin rights on a machine.

              $ mkdir -p ~/.local/src
              $ cd ~/.local/src/
              $ curl https://ftp.gnu.org/gnu/stow/stow-latest.tar.gz | tar xvf -
              $ cd stow-2.2.2/
              $ ./configure --prefix=/home/elasticdog/.local
              $ make
              $ make install
              1. 2

                As it’s just a Perl script with few dependencies you can also just install it into your dotfiles. You can then clone your dotfiles and literally stow stow (ala. cd dotfiles && stow/bin/stow stow). Now you have stow symlinked into ~/bin and you’re good to go :)

                1. 2

                  That’s a great point…I think I’ll steal that for my own setup. Thanks!

              2. 2

                I also just use a script. It seems so trivial to me, a new piece of software shouldn’t be necessary.

                1. 2

                  One feature of Stow that I find useful is the ability to undo the symlinks. I use that feature to install two versions of a program in /usr/local/stow and easily switch between the two.

                2. 3

                  I just use a .git in my home directory with * in the info/excludes file. It’s pretty risky – I’ve already had a git clean moment, so stow seems like a much better option.

                  1. 2

                    I found rcm a couple of years ago, and haven’t looked back.

                    1. 2

                      If you like Stow then you’ll love AppFS ( http://appfs.rkeene.org/ ). It’s Stow turned up to 100.

                      Some reasons why: 1. Writable (users changes are only visible to them and stored in their home directory); 2. Network based distribution – make the package and use it on all your systems; 3. De-duplication of files between projects, releases, and architectures; 4. Files from packages are only fetched if you use them, so development files from a package don’t take up disk space if you don’t do development and thus there is no need to create multiple variants of a package just to save space

                      And many more !

                      Feedback welcome

                      1. 2

                        I tried Homesick for a while but ultimately found it frustrating and prone to symlink corruption when dealing with nested dot files and trying to avoid putting some files under management.

                        I’ll give Stow a shot!

                        1. 1

                          I considered stow, but I finally decided to use yadm The main reason is because I can easily encrypt sensible files with yadm.

                          Also yadm works with my git aliases. So using yadm feels exactly like using git with my personal preferences.

                          1. 1

                            Hhm looks pretty interesting, does it support other vcs than git? And I think some of the password encryption stuff could be managed by something like pass

                          2. 1

                            I investigated both Depot and Stow, but ended up with Graft instead, which I believe far superior to both.

                            http://peters.gormand.com.au/Home/tools and more info at http://peters.gormand.com.au/Home/tools/graft/graft.html