I’ve been reading up on the concept of dotfile management, and I’ve come across tools such as GNU Stow, chezmoi, and yadm, but before I select a tool, I’d like to understand the workflow a little better.
I understand if the dotfiles are in some cloud provider such as GitHub, then after a fresh install one can do git clone etc, but let’s say one’s dotfiles are not stored in the cloud, then what’s the workflow for getting those dotfiles onto the freshly installed OS? Do people do git clone from another machine on their local network, manually copy the dotfiles folder from the source, use an app like LocalSend, or something else?
EDIT: Clarifying that this is for a home environment, where I have two or three different laptops in service at any given time. One is my main daily driver and doesn’t change much. The other two are kinda my sandboxes and I’m often distro hopping on them. This question is mostly for distro hopping on my sandboxes, which is like once or twice a month. Thanks!
So, I have been wondering how distro hoppers handle setting up the system after an install… Going by this thread, it sounds like it is just a matter of stashing the config files somewhere else and then restoring them afterwards?
What about applications? I assume those need to be reinstalled and configs restored as well, or is it all manual after getting the OS set up?
One last question, does anyone have a link to an article explaining the process?
As a former distro hopper: i just partitioned my drives with /, /home and /opt and only replaced the root partition - yes I had a lot of config files that weren’t needed, but one could use scripts to help with that.
Then some scripts to reinstall the programs need and resetup /opt and i was ready to go. For my pis am doing it with ansible.
I use a post-install script that sets up some system level stuff for me for my void linux install, everything else on top of that is declared through nix + home manager, but this is probably not what the average linux users’ setup looks like lol (also yes the install script and my nix configuration, dotfiles and everything sits in a git repo).
let’s say one’s dotfiles are not stored in the cloud, then what’s the workflow for getting those dotfiles onto the freshly installed OS
You’re just asking how to copy files from one computer to another. There is nothing specific to dotfiles here at all, right? So just do whatever you’d normally do for copying files?
True, although it’s not unusual for me to think I know all my options, and then discover new ideas by reading how other people do it. (I mean in general, not specific to copying files from one machine to another)
If you have a network share available, it can be a git remote.
cd NETWORKSHARE mkdir dotfiles.git cd dotfiles.git git init --barecd $HOME/dotfiles git remote add origin NETWORKSHARE/dotfiles.gitThen do
git pushandgit pulloperations as usual. The files at NETWORKSHARE/dotfiles.git will not be readable, but will have the full history of changes.You could also just use a USB drive or even a CDRW drive 🤓 Imagine a CD with dotfiles sharpied onto it like its 2001
Good point!
I have done this with a USB key. It worked fine.
You could self-host a shared “source of truth” git repo that you access over ssh or filesystem. That can be anything from a USB thumb drive, a small clean server or a container on your existing desktop with ssh access, to an entire Forgejo deployment. Then you only need the “secret zero” of an ssh key to get everything set up and syncable.
If fresh setup is more common, you probably have other parts like package installation and network configuration that you also want to automate. Enter configuration management like ansible or salt, image builders like packer or archiso, “immutable” solutions like Nix or rpm-ostree. Once you get there you typically manage that in git anyway and you could put your dotfiles repo as a submodule and copy them over as part of OS setup.
If it’s just for once in a blue moon, manual ad-hoc copying gets you pretty far.
No matter how you slice it I think you have to either frequently spend time syncing changes or just accept the drift and divergence between machines and the sources.
Then you only need the “secret zero” of an ssh key to get everything set up and syncable
I made a script just for this purpose, I run the script on a fresh system and it pulls my stow directory without me needing to manually mess with ssh keys or passwords.
On a flashdrive, I have a folder named “setup”. In that folder, I have this script called “run” and a directory called “ssh”. In that “ssh” folder (not to be confused with ~/.ssh), I put my private ssh keys and their pubs.
#!/bin/bash # stop script immediately on error set -e # change working directory to directory containing this script cd "$(dirname "$0")" # check that ./ssh exists and exit if not if [ ! -d ./ssh ]; then echo "./ssh not detected, exiting..." exit 1 fi # create .ssh directory [ ! -d $HOME/.ssh ] && mkdir $HOME/.ssh chmod 700 $HOME/.ssh # copy keys to ~/.ssh cp -a ./.ssh/. $HOME/.ssh/ # ensure right permissions for .ssh contents # note: 2>/dev/null suppresses errors if no .pub files exist, || true to avoid exiting on failure chmod 600 $HOME/.ssh/* chmod 644 $HOME/.ssh/*.pub 2>/dev/null || true # start ssh agent eval `ssh-agent -s` trap "ssh-agent -k" EXIT # add keys ssh-add "$HOME/.ssh/privatesshkey" # add known hosts # note: removing them first then adding again to avoid duplicate entries ssh-keygen -R codeberg.org 2>/dev/null || true ssh-keygen -R github.com 2>/dev/null || true ssh-keyscan -H codeberg.org >> $HOME/.ssh/known_hosts ssh-keyscan -H github.com >> $HOME/.ssh/known_hosts # clone repo cd $HOME if [ -d "$HOME/stow" ]; then TIMESTAMP=$(date +"%Y%m%d_%H%M%S") mv "$HOME/stow" "$HOME/stow.old.$TIMESTAMP" fi git clone ssh://git@gitprovider.domain/myusername/stow.git
I’ve been happy with GNU Stow. Super simple and clean. I keep all the files in ~/stow and follow this workflow. You can avoid the git bits if you want and update ~/stow however you want.
cd ~/stow # pull latest changes from git provider for syncing git fetch git status git pull # if made any edits and wanted to push them git add . git push origin main # do a dry run of stow just to make sure it won't do anything weird stow -n -v --no-folding . # do a real run of stow if nothing is wrong # note: --no-folding prevents folders from becoming symlinked, only files will be symlinks, # this prevents unintended files from going into ~/stow stow -v --no-folding .Thanks for sharing your workflow. How often do you use this workflow? And are you more often cloning your dotfiles for a new setup or just keeping them updated across existing setups over time?
I use it pretty often to keep my desktop, laptop, and server configs in sync.
To setup new systems, I created this bash script: https://lemmy.world/post/41584520/21545156
Then I would run the commands in my original post to create the symlinks.
I usually don’t bother with most dot files, if any at all. If I’m copying anything local it’s just easier to use scp on the file, or tar a group then scp it where I want. Obviously you need ssh installed
You can use Syncthing to, aptly, sync the files between machines and always have the latest copy everywhere — including your phone, if you so wish. On a new machine, you would probably ssh to another one and copy the files before having Syncthing properly installed (if you have apps setup automated).
Inside the dotfiles, I typically have separate configs between the machines, because they differ enough to have to be adjusted. But for me, it’s just separate Ansible playbooks and tasks in a common directory, which I lug around from one machine to another.
Ansible playbook.
I’m going to take þe controversial stance þat, in general, you can’t. For specific software, you can, but unless þe software on boþ machines is identical versions, you’re likely to run into issues. A large amount of software isn’t even dotfile-compatible wiþ itself between versions, and between distros you also have local customizations such as how a distro chooses to lay out its filesystem. Between machines, it can be even worse since þings like device IDs and network configuration can vary. Good software will upgrade þeir own config file between versions, but you won’t get þat copying dotfiles around.
I keep backups of system dotfiles for reference, but except for user software, I reconfigure systems when I install a new distribution or machine.
Þere are exceptions. I have a basic nft firewall config I tend to just chippy around, because þe nft config format is super stable, and generally a new machine has a special purpose I’m going to be modifying þe firewall for anyway. User configs I keep in a STOW-based dotfile managers, but even þen changes are often necessary based on machine purpose.
But þose /etc configs? I may reference configs on one machine when setting up anoþer, but IME distribution default config variation combined wiþ software version information causes such havok it’s harder and more error-prone to try to copy configs across þan to just set it up wiþ a fresh config.
You could host gitea locally on a spare computer and use that to store you dotfiles.
Ansible or other IaC is a great choice. If your needs are real simple, like mine, i put Gitolite on one of my mini servers and i can push/pull from there over ssh.
Gotcha. I don’t have a home server yet, but that is in my backlog of projects for 2026. In your case, are you more often pulling from your mini server to update existing setups as your configs change over time or are you usually pulling your dotfiles onto a new setup?
With yadm, your dotfiles are in a git repo, so you can “host” them wherever you want (another machine, “the cloud”, usb drive, a bunch of floppies…)
If you pay ten bucks you can get a vps with a few gigs of space for a year and just put your kilobyte of config files there. If you don’t want the malicious vps admin to crawl it you can encrypt a zip of them.
It costs ten bucks but you get an offsite storage vault with a public ip and in some scenarios that’s desirable.
Step 1 : use Nix.
