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.
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).
_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.
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?
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.
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.
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!
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).
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.
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.
23 comments
[ 2.9 ms ] story [ 58.9 ms ] threadDisclaimer: I'm the author of chezmoi.
Has somebody used both, and still uses stow? What is your experience with both?
[1]: https://yadm.io/
* 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
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?
By carefully managing scripts (mostly .zshrc) I can even use the same dotfiles between mac and linux.
What surprising behavior does it avoid?
Symlinks breaking perhaps? Anything else?
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 prefer homeshick[0], a Bash port of homesick[1] (which is Ruby).
[0] https://github.com/andsens/homeshick [1] https://github.com/technicalpickles/homesick
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.
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.