I have a custom tool built up over the years that keeps the history of that stuff in repos, but the actual files in ~/bin are usually hadlinks to the repo files (configurable - can be softlink or copy, too).
Every few weeks or months, I run a command on each system that gathers up any accumulated changes I've made to these files and syncs them to common machine that has all the repos. I merge those changes, then run another command to install the updates on all machines, so everything stays in-sync, over time.
I found that these ~/bin scripts and config files fell into a bit of a "donut hole" of development effort, where it was too much bother to maintain a full repo/build/install setup for every single script independently, but I did want to keep changes in sync and track them over time, rather than just having each system diverge forever.
So, my solution was to bundle lots of scripts together, into just a few repos, and sync/merge/etc them in bulk, to streamline the process.
A downside is lots of my commit notes are just a generic "gathering up latest changes" since I'm slurping up lots of edits to unrelated files at once. Hasn't really been a problem for me, though. I mostly just care about having the history.
There are tools to manage it for you that I’m sure someone will come along and mention, but I’ve got a repo I check out at `~/.home`, then a shell script they just symlinks everything into place.
So .bashrc is a symlink to ~/.home/.bashrc, ~/.config/nvim to ~/.home/.config/nvim, etc.
It’s simple and only relies on having something sh-compatible available so portable now and in the future.
To manage per-system tweaks, I have places that include an additional file based on hostname. For example my .bashrc has something like:
if [ -f “$HOME/.bashrc.$HOSTNAME” ]; then
source “$HOME/.bashrc.$HOSTNAME”
if
Which will include a bashrc file specific to that host if it exists.
My main system is windows, so it's c:/CmdTools repo in PATH. I tried to learn `stow`-likes, but it's not worth it. I just clone/pull/push it in that fixed location. Mostly cmdbash scripts.
More complex (multi-file) tools are usually separate ts or python projects. Node has {npm,yarn} link, which puts a starter .cmd somewhere in PATH, out of box. Python scripts I usually run through .cmd "alias" files in c:/CmdTools, there's no `pip link` afaik.
I always have MSYS2 installed and here's my cmdbash prolog:
some.cmd:
:<<BATCH
@xbash %~dpf0 %*
@exit /b
BATCH
for i in {1..5}; do
echo "Hello from bash!"
done
xbash.exe is just msys's bash.exe that I copied to avoid collisions with WSL (which is a useless PR nonsense). Same with xgrep, xfind, xecho, xmkdir, xsort.
This setup carried me for years and turns out to be a very reasonable windows/unix integration. I like unix architecture, but can't stand linux desktop. This year I've got a project related to linux desktop, and I'm literally become so stressed using it sometimes that I have to take a break or vent loudly.
My ~/bin directory is not directly version controlled. It primarily consists of symlinks, often stripping file extensions from shell scripts (e.g., ~/bin/foobar links to ~/src/foobar.sh) I have just enough python scripts and go binaries to make me think it's worth separating src and bin.
~/src is a git repo. One script evolved into its own project and became a submodule within ~/src.
For configuration files like ~/.foobar_rc and directories such as ~/.vim/, they again are not directly version controlled but are symlinked into ~/etc which is. I don't see any reason that ~/.foobar_rc couldn't be a hardlink, but it's not in my setup.
I used to maintain a single repository at ~ that included ~/src and ~/etc as submodules, with a build script for setting up links. Always being within a git repository became cumbersome, so I moved the build tools into their respective directories (~/src and ~/etc) and now clone and build each repository manually.
Lastly, since private repos aren't (weren't?) free, those submodule repos are really just branches of the same repo that share no common ancestors.
I have some essential stuff for zsh config in a git repo.
For my most important custom bins, they are written in Rust and published to crates.io so I cargo install them from there. It’s just one crate, with wrappers for the git commands that I use day to day
In addition to this, I have host specific repos with some scripts. These scripts are not in my path but are instead scripts that run on a schedule from cron. These scripts run and log various facts about the machine such as zpool status and list installed packages, and auto-commit and push those to their repo. And the other kind of script I have invokes zfs send and recv to have automatic backups of data that I care about.
In addition to this I have a couple other git repos for stuff that matters to me, which either runs via cron (retrieving data from 3rd parties on a schedule) or manually (processing some data).
For neovim I stopped caring about having a custom RC file at all. I just use vanilla neovim now on my servers. On my laptop I use full blown IDEs from JetBrains for doing work.
My dotfiles/configs are a mix of the following setup on boot:
- one-way copy of config file from $repo/$path to $path (prevents apps from modifying my curated config or adding noise)
- or make it a symlink (if I want it mutable)
- or make it a bind mount (if a symlink won't work; can be a file or folder)
- or make it a one way copy but add a file watcher to copy changes back to the repo (if none of the above work. Some programs fail if the file they need is a symlink or is bind mounted)
For dotfiles using a one-way copy, whenever I change a setting I want to persist I have to manually copy or edit the original $repo/$path. I can take a diff against the repo for a hint, or use `inotifywait -r -e modify,create,delete,move . ~/.local ~/.config -m` for something new.
Not using hard links since the dotfiles are likely to be on a different filesystem (or dataset) than their target paths.
I use a git repository `dotfiles` containing several configs in `dotfiles/etc/`.
Since I use `zsh`, I usually only symlink the `dotfiles/etc/zsh/.zshrc` to `$HOME/.zshrc`, while the `.zshrc` loads environment variables settings all required paths for my tools, e.g.:
I keep everything I care about in a dot-files repo that knows what to install where in different places. I wrote a little tool to make it easier for me to do this: https://github.com/oalders/is
Since the link directives are idempotent, you can run it on every login shell if you desire. I ended up setting up a shared jumpbox used by some contractors with it so they could work with our internal tooling without requiring excessive setup, and wrapped it into a shell startup script[2] and found it performant enough that I couldn't tell the difference.
I use chezmoi - it handles both elegantly & has no real requirements w.r.t. how you choose to structure your filesystem. It also handles recovery well when you mess things up.
- is your ~/bin directory a git repo?
- if you git to manage your dot files, do you use hard links or soft links?