
Using GNU Stow to manage dotfiles (2013) - pmoriarty
http://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html
======
tga
I'm a happy follower of [https://legacy-
developer.atlassian.com/blog/2016/02/best-way...](https://legacy-
developer.atlassian.com/blog/2016/02/best-way-to-store-dotfiles-git-bare-
repo). Just a plain Git repository in $HOME, no other tools required. This
makes it instantly portable to any machine (with git).

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

~~~
tga
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.

~~~
notheguyouthink
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.

------
meribold
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](https://github.com/meribold/dotfiles)
[2]: [https://dotfiles.github.io/#general-purpose-dotfile-
utilitie...](https://dotfiles.github.io/#general-purpose-dotfile-utilities)

~~~
davidmr
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](https://github.com/davidr/dotfiles)

------
kaushalmodi
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.

------
lamlam
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/](https://github.com/anishathalye/dotbot/)

------
philsnow
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 .

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

[https://github.com/lovullo/bash-d](https://github.com/lovullo/bash-d)

------
grawlinson
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. :)

~~~
solatic
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.

~~~
Mic92
alternative: [https://github.com/rycee/home-
manager](https://github.com/rycee/home-manager)

------
msimpson
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.

------
lutostag
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](https://github.com/lutostag/dotfiles)
[2]:
[https://thelocehiliosan.github.io/yadm/](https://thelocehiliosan.github.io/yadm/)

------
aviaviavi
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](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.

------
todd8
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.

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

------
gtf21
> 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`?

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

