Show HN: Lnk – Git-native dotfiles manager

     export MY_TOKEN="$(pass token | head -n 1)"

Then you can just not track that file in the tool and figure out a safe way to back it up.

And it adds "how safe are those encrypted secrets [edit: changed from "keys" to more general language] that are committed?" and "what about previous revisions . . . because it's version control?" and "are we sure we're managing offboarding securely?"

There are probably other concerns but those are the ones the immediately shout at me.

GNU Stow: - Package-based structure: Requires organizing dotfiles into "packages" (subdirectories) - Symlink-only: Just handles symlinking, no version control integration - Manual Git: You manage Git separately (git clone → stow package-name) - Perl dependency: Requires Perl to be installed - No safety net: No atomic operations or rollback if something goes wrong

lnk: - File-based workflow: Takes your existing dotfiles as-is, moves them to managed location - Git-integrated: Wraps Git commands (lnk push, lnk pull) for seamless workflow - Atomic operations: If something fails, automatically rolls back changes - Single binary: No dependencies, just download and run - New machine workflow: lnk init -r repo && lnk pull handles clone + restore in one step

Key Difference in Workflow:

Stow approach: # Organize files into packages first mkdir -p ~/.dotfiles/vim/.config/nvim mv ~/.config/nvim/init.lua ~/.dotfiles/vim/.config/nvim/ git add . && git commit # On new machine: git clone repo ~/.dotfiles stow vim # Creates symlinks

lnk approach: # Start with files where they are lnk add ~/.config/nvim/init.lua # Moves and links automatically lnk push "added nvim config" # On new machine: lnk init -r repo && lnk pull # Clone + restore in one command

Bottom line: Stow is a pure symlinking tool that you combine with Git manually. lnk is an opinionated workflow that handles the entire dotfiles lifecycle (move → version → sync → restore).

In any case you can manage your bashrc/profile and handle conditional logic to install packages there.

```if command -q exa alias ls="exa" alias ll="exa -lah" alias tree="exa --tree" end

if command -q eza alias ls="eza" alias ll="eza -lah" alias tree="eza --tree" end```

I believe one could even add stuff like `!.bashrc` to the gitignore so it can keep track of these files automatically. Hence we could have template .gitignore for most common use cases.

I love the bare repo method though. I’ve been using it for several years and haven’t had a need for another

- 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.

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?

I don’t remember a problem with dotfiles. I’m sure there were ones that maybe I got used to.

I also use it for ~/bin scripts. There the limitations are more noticable.

Stow plus Git is a setup that already “doesn't suck.” Whatever that means here.