Well, that's what you end up with. Stow just automates the "symlink those files part".
stow links based on the directory structure of the folder you're calling, so I don't have to worry about where things are, just stow fish; stow nvim
There's no symlink script or adapter script to work with stow, everything 'just works' for me.
I prefer to skip the symlinks, and just directly use the git repository as my home directory. (I have a sizable .gitignore for things I don't want to track.)
The only drawback to the homedir-as-git-repo approach I've found is that you're always in a git repo, so you have to be careful not adding stuff which was really supposed to go in another repo.
https://www.atlassian.com/git/tutorials/dotfiles
TL;DR:
alias dotfiles='/usr/bin/git --git-dir=$HOME/src/dotfiles --work-tree=$HOME'
dotfiles add
dotfiles commit
...Does anyone know if syncing a git repo over Syncthing (or similar) is a good idea or whether there are likely to be conflicts? I don't know if git names its files such that conflicts aren't possible.
I tend to always run "git status" before adding anything, which makes it fairly obvious what repository I'm in. (Or I'm working via fugitive in vim, which helps in the same way.)
1. If you want to delete a file, you have to delete it (rm) in one place and delete it another way in another place (git rm).
2. Adding a new file in-situ (in the home directory) requires some finessing to get it back into the git repo and symlinked properly.
3. No easy way to apply a rename operation.
4. After changing the checked out branch, there is no easy way to apply these changes to the home directory.
/*
!git/config
!tmux/tmux.conf
Works great for me.
All you need to do is to keep track of symlinks you've installed with your setup script. This can be done by creating a symlink to the symlink you've installed, which acts as a "GC root." The next time you run the setup script, it would check those "GC roots" to see if they point to a valid file and remove any dangling symlinks.
This is the approach I take for my own dotfiles. I seriously considered using Stow or the bare git approach before, but I decided against it because setting up my dotfiles involved more than just installing symlinks. I had to be able to download files (e.g., vim-plug), clone git repositories, change file permissions, and maintain files that's not meant to be linked into the home directory. I found the flexibility of a custom shell script most fit for my needs.
[1]: The "Deleting Packages" section in https://linux.die.net/man/8/stow
I use `rm` all the time in git repos... Just `git add` when it is time to stage changes.
That's a feature.
I did not use stow 2.x, but my understanding is that running stow -R will allow you to remove previous dangling symlinks (during the unstow) and add missing symlinks (during the restow). Effectively allowing you to only manage a single state: your git repository.
I also don't have all dotfiles under version control, just the ones I've essentially "built myself", so maybe that makes it easier.
Yes though, use a repo for sync, but stow takes care of at linking your dot files in the right place.
Nothing wrong with tracking dotfiles with Git. It's probably the simplest and easiest approach without requiring any fancy tools other than Git. However, as mentioned in ArchLinux's wiki page, the disadvantage of Git approach is that "host-specific configuration generally requires merging changes into multiple branches."[1]
[1]: https://wiki.archlinux.org/index.php/Dotfiles#Tracking_dotfi...
EDIT: 12+ years at work.
This is exactly what Stow does.
Exactly! I do exactly that. I have an install.sh script that simply iterates over the files and directories in my dotfiles repo and does mkdir and ln
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.
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: https://github.com/nickjj/dotfiles
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.