News for hackers. Stuff that matters.
Re:Using GNU Stow to manage your dotfiles (2012) by coldtea on Monday December 28, 2020 @07:33PM (#25565134)
>Right, but when you unlink it from your home directory, the file still exists in the git repo.

That's a feature.

Re:Using GNU Stow to manage your dotfiles (2012) by ironmagma on Monday December 28, 2020 @07:37PM (#25565179)
Not when you are looking for a workflow to make dealing with dotfiles faster and more painless. With the current (symlink based) setup, there is a hidden state you must hold in your head or else carefully inspect: the discrepancy between your git repo and your home directory. Maybe you forgot to link a dotfile, and that’s why your latest configuration doesn’t work. Ditto for unlinking a dotfile.
Re:Using GNU Stow to manage your dotfiles (2012) by Galanwe on Monday December 28, 2020 @08:32PM (#25565619)
Isn't that what -D, -S, and more simply -R do?

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.

Re:Using GNU Stow to manage your dotfiles (2012) by kelnos on Tuesday December 29, 2020 @03:59AM (#25568007)
I delete dotfiles so infrequently (once a year?) that this just isn't a problem for me.

I also don't have all dotfiles under version control, just the ones I've essentially "built myself", so maybe that makes it easier.

Re:Using GNU Stow to manage your dotfiles (2012) by macintux on Monday December 28, 2020 @08:27PM (#25565574)
`git rm` will still leave the file available in the repo history, so violating the consistency seems more like a bug than a feature.
Re:Using GNU Stow to manage your dotfiles (2012) by coldtea on Tuesday December 29, 2020 @04:38AM (#25568206)
Still a feature. You might want to revert back to it. And history is history.