Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go?<p>If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living across 2 systems (such as WSL 2 and Windows) where on a Windows box you consider certain Windows files dotfiles even though technically they exist elsewhere.<p>I've been managing my dotfiles like this for a few years and it seems to be working out well not just for myself but others who have want to use them either partially or in full. I open sourced them here: <a href="https://github.com/nickjj/dotfiles" rel="nofollow">https://github.com/nickjj/dotfiles</a><p>I purposely broke up some of the commands because I know that not everyone will want a 100% replica of my dotfiles. Folks copy / paste only the commands they want.
STOW is great, it is simple and works well especially combined with git. That's what I do [0], and recently combined it with org-mode for literate programming, so each program has just a README.org that then generates all the files via org tangle [1] [2]. For example, here is my file that generates my Xorg configuration [3] over several files, nicely readable on GitHub, in Emacs, or just as plain text.<p>[0] <a href="https://github.com/podiki/dot.me/" rel="nofollow">https://github.com/podiki/dot.me/</a><p>[1] <a href="https://web.archive.org/web/20190924102437/https://expoundite.net/guides/dotfile-management" rel="nofollow">https://web.archive.org/web/20190924102437/https://expoundit...</a><p>[2] <a href="https://orgmode.org/manual/Working-with-Source-Code.html" rel="nofollow">https://orgmode.org/manual/Working-with-Source-Code.html</a><p>[3] <a href="https://github.com/podiki/dot.me/tree/master/x11" rel="nofollow">https://github.com/podiki/dot.me/tree/master/x11</a>
I have found that managing dotfiles is not enough. The dotfiles serve no purpose without the software that uses them. My method is to write small scripts, I call them setuplets, that install the software and then symlink the dotfile to its master that I manage in git. In the simplest case, it is just a two line script in a directory, but I have one for each program, and a tool to select which I run when setting up a new linux machine. The more complex ones may install a number of tools and set up environment variables etc. For environment variables, the script drops a script file in a directory, where my bashrc sources it.
You don't need symlinks, setup scripts, etc. Try this:<p>1. Bare git repo in your home directory ($HOME/.files)<p>2. Alias for prefixing git commands ("env GIT_WORK_TREE=$HOME GIT_DIR=$HOME/.files")<p>3. Strict .gitignore file (that ignores all files by default)<p>Simple to add files: `h git add .vimrc`<p>Have this set up for myself. Works great <a href="https://github.com/tmm/dotfiles" rel="nofollow">https://github.com/tmm/dotfiles</a>
I use this technique, based on a bare git repo <a href="https://www.atlassian.com/git/tutorials/dotfiles" rel="nofollow">https://www.atlassian.com/git/tutorials/dotfiles</a><p>Works quite well ... but I'm really, really ready for a rebuild of how Linux systems are built. I hope systemd-homed will deliver.<p>Imagine you could ssh into a machine with a flag that forwards your local config. Or even your local bin.
I really like this method as opposed to using a bare Git repository. For one, it's conceptually simpler in my mind; you don't have to understand Git internals to get this working. Secondly, this lets you pick and choose which config files you want to "install" on a machine.<p>I feel obligated to share my Bash script, dotfiles.sh[1], that accomplishes what Stow does, but with a few tweaks that I found particularly useful:<p>dotfiles.sh targets the user's home directory by default (i.e. stow -t $HOME).<p>dotfiles.sh never symlinks directories, only files (i.e. stow --no-folding). (This was the straw that broke the camel's back and made me roll my own script in the first place.)<p>dotfiles.sh makes backups of local config files and can restore them if you remove your symlinked version.<p>My script is quite old now, and I use it so seldomly I'm not convinced there aren't bugs. YMMV.<p>[1]: <a href="https://github.com/kevin-hanselman/dotfiles" rel="nofollow">https://github.com/kevin-hanselman/dotfiles</a>
I'm very happy with yadm (<a href="https://yadm.io/" rel="nofollow">https://yadm.io/</a>) – it's a thin wrapper around git that adds things like alternate and templated files to use different versions of a file or to switch out part of a config for different systems and built-in support for secrets (not using the latter myself, but it's there)
I’ve been using stow to manage my dotfiles for a long time, works very well.<p>Recently I’ve moved to NixOS and have been considering trying out Nix’s home-manager (mostly just out of curiosity - I’m perfectly happy with stow). If anyone has tried both stow and home-manager, I’d be interested to know your thoughts on how they compare.
I like dotbot [0] and have been using it for a while. How do people manage secrets, I am encrypting with keybase, but really want to move away from it.<p>[0]: <a href="https://github.com/anishathalye/dotbot" rel="nofollow">https://github.com/anishathalye/dotbot</a>
I reinstalled my OS (actually, a jump to an adjacent distro) just last night and was thankful I had set up a dotfiles manager (yadm [0]). yadm is a git wrapper, so a yadm repository is pretty much a git repository.<p>`yay -Qe | cut -f 1 -d " " > .config/packages.txt` to back up my packages (without version), push to remote, and then `cd ~ && yadm clone -f <remote> && yay -S $(cat .config/packages.txt)` to reinstall everything. Piece of cake.<p>The only thing I am missing is tracking system files, like /etc/pacman.conf, and it looks like there's a way to do it with yadm, but it looks a bit clunky and I haven't tried.<p>[0] <a href="https://yadm.io/" rel="nofollow">https://yadm.io/</a>
I follow a similar but handcrafted approach. I have a dotfiles repo with a setup script that automates the creation or deletion of all the symbolic links: <a href="https://github.com/susam/dotfiles/blob/master/setup" rel="nofollow">https://github.com/susam/dotfiles/blob/master/setup</a><p>So what I do on any new system is just:<p><pre><code> git clone https://github.com/susam/dotfiles.git
cd dotfiles
./setup
</code></pre>
And if I want to undo all the setup for some reason:<p><pre><code> ./setup rm</code></pre>
I love stow. My only complaint is that I cannot seem to remember the name of the command: Is it "grab", "collect", "pirate", "organize", "install", "push", "pull", ...?<p>So I added a note to myself into my .bashrc about this command, and patted myself on the back. The next time I reinstalled Linux, I couldn't remember the name, but I remembered that I wrote a note to myself about it. So opened up my .bashrc, and... I didn't feel so smart.
I am sure there is a better way but I just do this. It works well enough for my purposes.<p>cd ~<p>git init<p>git remote add origin [URL]<p>git fetch<p>git checkout -f master
Sounds interesting, but I can't help but wonder:<p>> all your dotfiles are now neatly organised<p>isn't that what .config is for?<p>> install locally built packages in /usr/local/stow/PKGNAME-VERSION [...] so you don’t have to worry about any stray files<p>Isn't that what /opt is for?<p>> (HN comments live-linking to a repository)<p>So maintain externally and export as needed.<p>... am I missing some really important context here? I downloaded stow to check it out, but the whole 'dotfile/installation' use-case in the article sounds like a nothingburger to me.
Some more ways to manage dotfiles are linked from the vcs-home wiki:<p><a href="https://vcs-home.branchable.com/" rel="nofollow">https://vcs-home.branchable.com/</a>
I did my own super-simple Python script[1] with zero dependencies for symlinking files between multiple computers and platforms.<p>[1] <a href="https://gist.github.com/XVilka/f124936a336a5a43f54915369719e626" rel="nofollow">https://gist.github.com/XVilka/f124936a336a5a43f54915369719e...</a>
I originally went with the bare git repo technique, but found myself not liking how to store multiple computer's dotfiles in a single repo.<p>I ended up switching to <a href="https://www.chezmoi.io/" rel="nofollow">https://www.chezmoi.io/</a>, after learning about it here on HN.
There are a ton of utilities for managing dotfiles. Some of them are listed here: <a href="http://dotfiles.github.io/utilities/" rel="nofollow">http://dotfiles.github.io/utilities/</a>
It’s over-engineered, but I’ve been using <a href="https://github.com/RichiH/vcsh" rel="nofollow">https://github.com/RichiH/vcsh</a> for this for years.
Is this project's name a pun on "gnusto"? That's the spell in the Infocom game "Enchanter", which copies a spell into your spellbook.
Have GNU reinvented the Windows registry?<p>Obviously the Windows registry works terribly in practice, but the idea of a centralised store seems to be coming back into fashion.
For this I highly recommend <a href="https://zolk3ri.name/cgit/zpkg/" rel="nofollow">https://zolk3ri.name/cgit/zpkg/</a> which I have been using for years now. It works wonderfully for my use case, and might work for yours, too. It is very simple.<p>Environment variables and their defaults:<p><pre><code> ZPKG_SRC = ~/.local/pkg
ZPKG_DST = ~/.local
ZPKG_DB = ~/.local/pkg/.db
</code></pre>
It means that if you install anything from scratch, you have to `<i>make install</i>` (or the like, depending on the build system) it to, say, `<i>~/.local/pkg/foo-1.0</i>` and then run `<i>zpkg link foo:1.0</i>` to install (i.e. link) the "package".<p>After that you just have to make sure you have (typically in your `<i>~/.bash_profile</i>` file):<p>- added `<i>~/.local/bin</i>` to your `<i>PATH</i>` environment variable, and<p>- added `<i>~/.local/man</i>` to your `<i>MANPATH</i>` environment variable<p>Seems to do the job. For help, read the source code or type `<i>zpkg --help</i>` which should be of tremendous help.<p>By the way, I have noticed that someone created a package manager with the same name, but its initial commit was in 2019, while this one's was in 2017.<p>It is written in OCaml, so you do need to have the OCaml compiler installed. I recommend doing it via `<i>opam</i>`, but your Linux distribution's package manager will suffice (simply `<i>ocaml</i>` on Arch Linux, for example). Run `<i>make</i>` to compile it, it will produce a working executable file.<p>Direct link to the source code: <a href="https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml" rel="nofollow">https://zolk3ri.name/cgit/zpkg/tree/src/zpkg.ml</a><p>If you find any bugs, report it via e-mail which can be found in the `<i>LICENSE</i>` file. I reported a bug before and it was fixed almost immediately. I suppose you can send pull requests or mention missing features, the creator seemed friendly to me.<p>---<p>The above is a modified version of an old comment of mine: <a href="https://news.ycombinator.com/item?id=24238587" rel="nofollow">https://news.ycombinator.com/item?id=24238587</a><p>---<p>To be frank, I forgot how it compares to GNU Stow because it was many years ago, but I did use GNU Stow prior to finding this program. All I remember is that it is way simpler, and it seemed to be perfect for my use case, no more and no less than what I needed. Maybe it works for you, too.