Show HN: Manage Dotfiles with Stow | Hacker News Reader

Show HN: Manage Dotfiles with Stow

github.com

33 pointscodejamninja23 comments

_The_ method to manage dotfiles is to use git bare repos. [0-1] Its the ideal method as:

* It doesn’t require any configuration except for a ‘git init’ once & an alias (no symlinks, no b.s.)

* Files are version-controlled

* It’s unintrusive & universal: Because it doesn’t move any files or do anything special, there’s no surprising behavior, and you can try out a few files & stop using it with an rm -rf

* and on and on...

I strongly recommend eveybody trying out, no meed for configuration/mapping, and it’s easy to try out.

[0]: https://news.ycombinator.com/item?id=11071754

[1]: https://www.atlassian.com/git/tutorials/dotfiles

Bare repos are fine, but I don't think it is the method to manage dotfiles, the other approaches people use, stow among them, have their merits too. For me a bare repo never really worked that well. I use different dotfiles "profiles" that I mix and match for different environments (remote server, docker container, dev workstation, ...) and situations (terminal, xorg, dev, testing, etc.). I found a bare repo less than ideal for this, personally. It's perfectly fine for simple setups, granted.

I think one reason some people prefer symbolic links over directly managing $HOME with git is that there's less chance that things go wrong due to a bad accidental git command. For example, `git clean` (with the appropriate arguments, e.g. '-fdx') could delete all non-dotfiles from all of $HOME.

Admittedly, the chance of this happening does seem much lower when the git directory is in e.g. '~/.cfg/' while the work tree is $HOME, as the linked article proposes, than when it's set up with just a `git init` run in $HOME (because a `git clean` in a non-git-repository directory somewhere under $HOME won't cause any problems, because there will be no '--work-tree' argument). Still, at least to me, the symlink approach feels more comfortable.

I wonder, does anyone else have other reasons to prefer symbolic links?

I can't use this because I'd like to be able to put files outside of $HOME :(

I prefer dotfiles too, I recently built a new machine and was able to configure most of stuff just by using dotfiles.

By carefully managing scripts (mostly .zshrc) I can even use the same dotfiles between mac and linux.

> no surprising behavior

What surprising behavior does it avoid?

Symlinks breaking perhaps? Anything else?

Does it work for all kinds of files ???

that’s the way everyone first tries it

It is not.

Also consider https://chezmoi.io/ which has many advantages over Stow+git (e.g. manage files that vary across machines, password manager integration, transparent encryption, create real files not symlinks, dry-run and diff modes, and many more).

Disclaimer: I'm the author of chezmoi.

By the way, the link to the install instructions is broken on the front page, however the sidebar link works.

Thanks for the report :) Fixed.

looks like a great project, but it’s more complicated than dotstow

Books great

Looks like a nice wrapper around Stow+git, which is great! Make sure to add to https://dotfiles.github.io/ for the exposure, and read through the solutions described there for ideas for future improvements.

I have used stow before but I don't always want to name files what they are named.

When I want to edit a file I type vim but I can't always remember what the name of the file. I use tab to cycle through the files but it doesn't show dot files. I then have to type . then tab through the files.

I find this pretty annoying so I remove the dots in my dotfile repo but then stow wasn't symlinking to the correct file since there should be a dot

Does anybody have a solution that lets you alias files but still use stow or an alternative?

I don't want to write my own script or change the behavior of tabbing through files to also show dot files.

Five years ago we had a really broken production and development setup which required working on remote machines that we reset each week. I spend a lot of time ricing my setup but could not find a dotfile management tool that would fulfill all my needs - so naturally, I wrote one - of course ^^

And I still use it today even though we quickly switched to docker after realizing what mistake we made.

Anyhow this is the thing I use https://github.com/kairichard/lace together with my dotfile configuration https://github.com/kairichard/dotfiles/blob/master/.lace.yml

I've moved a while back to yadm[1], and largely prefer it over stow.

Has somebody used both, and still uses stow? What is your experience with both?

[1]: https://yadm.io/

I do have a simple Bash tool similar to Stow. It behave differently in some situations which I consider better for installing dotfiles. If you are interested: https://gitlab.com/semente/summon

Tested on GNU/Linux only. I appreciate feedback of OSX/BSD users and pull requests to increase its compatibility with systems other than GNU/Linux.

You don't need this. Just put your dotfiles in a structure stow likes and use stow without any other tooling. I'm using stow for years without any complicated setup or any other library or tools. It's great and I never have a problem!

I use https://github.com/lra/mackup and love it. Takes care also about application configs.

stow is nice, but it's too basic once you start managing your homedir in earnest across multiple machines and need machine-specific configurations, secrets, etc.

I prefer homeshick[0], a Bash port of homesick[1] (which is Ruby).

[0] https://github.com/andsens/homeshick [1] https://github.com/technicalpickles/homesick

I built dotstow as a simple way to combine 2 really great technologies, git and stow.

Reply on news.ycombinator.com