Personally, I use git [0] along with GNU stow [1], combined with making the files directly from a literate Readme.org (e.g. [2]). I sync this repository between machines to update files, and when I make changes in the org-mode Readme file it automatically generates the new file. There are ways to pull in changes made to that file directly, but haven't needed to do that. My repo doesn't walk you through it completely, but I think is pretty straightforward. If you want to see it in action along with a few links and pointers, do take a look at [0]. I really like having it all together in one place, and with org-mode everything is very (human) readable.<p>[0] <a href="https://github.com/podiki/dot.me" rel="nofollow">https://github.com/podiki/dot.me</a><p>[1] <a href="https://www.gnu.org/software/stow/" rel="nofollow">https://www.gnu.org/software/stow/</a><p>[2] <a href="https://github.com/podiki/dot.me/blob/master/x11/README.org" rel="nofollow">https://github.com/podiki/dot.me/blob/master/x11/README.org</a>
I've been using this bare repository approach for a while. I forget where I first saw it, I'm pretty sure it was on HN but it was not this project. I do like it, but I have a few minor issues.<p>The first is that I have a habit of running `git add .` when I'm working on source code, and as a result I have accidentally added my entire home directory to the bare repo more than once... Easy enough to undo but a bit inconvenient. `dotfiles add -u` is the safe option, or just be explicit about which files you are staging.<p>The second issue is the 'branch per machine' approach, which I do use. I have two machines I use regularly, and a third occasionally. There are some bits of config (e.g. for vim) that are shared across all the machines, while other bits are not. If I use one machine for a while, then I end up with lots commits that I need to cherry pick when I next use another machine. Depending on how long it has been, this can be a bit of a faff.<p>Finally, because there is no clear mainline branch, you have to pick commits to/from any of the branches. If you are undisciplined like me, then this will leave you with a 'three way ahead and behind' scenario at some point.<p>Anyway, I like the approach overall. If anyone has a suggestion to ease those pain points I'm all ears.
Just throwing my solution for dotfiles synchronization into the mix as well here, homeshick:
<a href="https://github.com/andsens/homeshick" rel="nofollow">https://github.com/andsens/homeshick</a><p>Maintained for 8 years now, 1.7k stars, only needs git >=1.5, bash >=3, and no root access to install.<p>It's well tested, stable, and super hackable to fit your needs.
I just maintain an install script to do the linking. It's just a few lines of zsh to mirror one directory into another with symlinks.<p>I've found that the bare repo approach has too many rough edges, and that the various dotfile management frameworks are overkill.<p><a href="https://github.com/cbarrick/dotfiles/blob/master/home/install.zsh" rel="nofollow">https://github.com/cbarrick/dotfiles/blob/master/home/instal...</a>
Often enough, when I see something like this, the real value isn't the software itself, but the idea that perhaps the issue it addresses is worth thinking about a bit more. The solution itself may be trivial, but have a large impact.<p>E.g. I have created [0] the simplest of scripts for managing updates for manually-installed / source-compiled applications (something I've dubbed "misc", very proud of this backronym :p).<p>The script itself is extremely simple (just a list of greps over latest release announcement urls), but it has solved a big problem for me, of helping me keep such "misc" items seamlessly up-to-date.<p>[0]: <a href="https://github.com/tpapastylianou/misc-updater" rel="nofollow">https://github.com/tpapastylianou/misc-updater</a>
Any love for rcm [1]? I settled on this after trying many dotfiles systems - works for me with just the right feature set. I don't often see it mentioned on dotfiles discussions online though.<p>[1]: <a href="https://github.com/thoughtbot/rcm" rel="nofollow">https://github.com/thoughtbot/rcm</a>
I do a similar thing, but with dotbot instead <a href="https://github.com/anishathalye/dotbot" rel="nofollow">https://github.com/anishathalye/dotbot</a>
Bare git repos are fine for starting, but you quickly hit limits if you want to use your dotfiles on different machines, e.g. share your .zshrc config between Linux and macOS.<p>A comparison of popular dotfile managers:<p><a href="https://github.com/twpayne/chezmoi/blob/master/docs/COMPARISON.md" rel="nofollow">https://github.com/twpayne/chezmoi/blob/master/docs/COMPARIS...</a>
I sync a directory of dotfiles across my workstations using syncthing. The .bashrc and .profile simply do:<p><pre><code> for FN in ~/.paths/sneak-sync/bashrc.d/*.sh ; do
source $FN
done
</code></pre>
Then updates (by adding or removing files to these directories) propagate to all my workstations. I have machine-specific ones, too, that also sync but aren't included due to differing hostnames.
I never liked the git bare repository approach, because it's each to accidentally add files to it that you don't intend (if you forget to run git init in a new project directory; or if some code generator decides to "re-use" your existing git repository). I prefer the symlinks approach, but I never liked how all of the symlinks managers tend to leave broken symlinks all over the place.<p>That's why I created my own solution, which maintains a state file in the repo, so doing something like deleting a config file or switching a git branch doesn't result in a bunch of broken symlinks lying in your system.<p><a href="https://github.com/cgamesplay/dfm" rel="nofollow">https://github.com/cgamesplay/dfm</a>
I've had my dotfiles under version control for over a decade (hg for a couple years, then git). I've never used or felt the need for any special tools, and I don't use any extra symlinking.<p>If you do that stuff, great, but here's what I do if you don't want to use any specialized tools:<p>My home directory is just a git repo. There's a regular old ~/.git directory. All of the management I do is regular git stuff, like any other repo. Everything I don't want to commit is listed in .gitignore, like any repo.<p>The only wrinkle is setting up a new machine. You can't clone into an existing directory (AFAIK), and your home directory already exists, so you need a workaround. An easy solution: clone the remote repo to ~/dotfiles, then `mv ~/dotfiles/.git ~`, then `rm -r ~/dotfiles`. Now your home directory is a git repo where the working copy is exactly as the home directory was before, and HEAD points to your repo's default branch. It will be dirty because all of your config files are missing. Use regular `git status` to take a look. It's always looked fine to me, so I `git checkout .`, which effectively installs the dotfiles. Then I'm done until I need to do that copy trick again when I buy my next computer. In the meantime I just commit and push as normal, and occasionally add a new file to .gitignore.
I've found that a simple dot_files directory that is sync'd via a public git repository [0] works well for me. When I'm on a new machine all I need to do is clone the repository and run `ln -s ~/dot_files/bash/bashrc ~/.bashrc`. The bashrc file then takes care of everything else.<p>It might not work for every program out there, but it does for the small number that I use.<p>[0] <a href="https://github.com/andypea/dot_files" rel="nofollow">https://github.com/andypea/dot_files</a>
How do people manage the platform differences between Linux, macOS, Windows WSL, Windows Cygwin, Solaris (at one point I had it on my NAS); and environment differences, such as work machines vs home machines?<p>I have my own dotfiles mechanism which splits out paths and configs by operating system, portable runtimes (e.g. Mono - may work on different OSes) and environments (enabling home and work configs to be stored in a separate repo and avoiding data leakage). Things like .bashrc and .bash_profile are assembled piecewise from fragments in each component.<p>Modifications to generated files by installers (notoriously, things like rvm, nvm etc. all want their stuff to be last in the config file, first in the path and all that) are detected so they can be integrated and not accidentally overwritten.<p>It's somewhat complex - I'm deliberately not linking it because I wouldn't recommend other people use mine, I have no time to support it - but to my mind these features are critical for any dotfile management system.
Since we're sharing, my dotfiles setup has pretty much reached its final form. I use my symgr[1] to symlink my dotfiles repo into my home dir. Pretty much everything I think about this topic is in its readme, as well as a link to my setup[2] repo with my dotfiles showing how I use symgr.<p>[1] <a href="https://github.com/kbd/symgr" rel="nofollow">https://github.com/kbd/symgr</a><p>[2] <a href="https://github.com/kbd/setup" rel="nofollow">https://github.com/kbd/setup</a>
I would highly recommend zero-sh[1] for those looking for a consistent simple tool to manage dotfiles on a mac.<p>1. <a href="https://github.com/zero-sh/zero.sh" rel="nofollow">https://github.com/zero-sh/zero.sh</a>