[hk1337]

I like the method I saw on atlassian and haven’t needed any other option.

Clone to a bare repo and make your home directory the git home. Then I can easily edit the files and push changes.

https://www.atlassian.com/git/tutorials/dotfiles

The whole symlink thing seems like a kludgey mess and pain in the ass to manage

Even GNU Stow seems like a pain

[mathstuf]

One big benefit of symlinks (really, "not storing it in the deployment") is that my Git repo doesn't have a bunch of hidden files in it because they can appear in the link's path rather than the repo's path. I can also split up files based on "why it exists" rather than "where it lives". For example, I can have the "enable Rust support" group of configurations:

- add Rust things to the list of packages to install - add any Rust-specific configurations for Neovim and `zsh` - bring in any Rust-oriented Neovim plugins

These files all then live next to each other rather than being scatter-shot between Neovim, zsh, and some giant list of packages. Additionally, if I later decide to disable "Rust support" on a machine, the broken symlinks in `$HOME` let me clean up easily without having to actually excise things from the repository.

That said, I have my own system that I built up years ago and it's never been abstracted out for anyone else to use so of course it's going to fit my needs better than anything else.

[threecheese]

Interesting; these methods seem to follow the same pattern. They both track specific files in a controlled bare git repo, and both transparently link a $HOME file into that repo. Differences are the git method “links” - within the work tree - while ‘lnk’ creates a filesystem link. They both require a special command - a shell alias, vs an installed binary, and both indirectly leverage git subcommands (via the shell alias or the binary).

An advantage of the git method is it doesn’t touch $HOME, and so if the git repo gets wiped out there’s no harm. Am I missing anything?