4 ms·

Not sure if Stow fixes these, but here are some problems I've had with that setup: 1. If you want to delete a file, you have to delete it (rm) in one place and

Not sure if Stow fixes these, but here are some problems I've had with that setup: 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.

cipherboy 6y ago
> and delete it another way in another place (git rm). I use `rm` all the time in git repos... Just `git add` when it is time to stage changes.
- ironmagma 6y ago
  Right, but when you unlink it from your home directory, the file still exists in the git repo. So there is a manual synchronization that must happen between the two directories.
  - coldtea 6y ago
    >Right, but when you unlink it from your home directory, the file still exists in the git repo. That's a feature.
    - ironmagma 6y ago
      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.
      - Galanwe 6y ago
        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.
      - kelnos 6y ago
        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.
    - macintux 6y ago
      `git rm` will still leave the file available in the repo history, so violating the consistency seems more like a bug than a feature.
      - coldtea 6y ago
        Still a feature. You might want to revert back to it. And history is history.
ljm 6y ago
If all your configs follow the XDG spec then you can turn ~/.config itself into the repo,and then use .gitignore as a whitelist: /* !git/config !tmux/tmux.conf I do this and clone my repo directly to .config on a new machine. The only hold out was tmux but that's solved by installing or compiling one of the recent versions released this year (3b/3c). I'll still use manual symlinks for things like bash, but they're outliers. Works great for me.
midchildan 6y ago
I believe Stow can fix everything except #2 [1], although I haven't actually used it before. But it's also easy to create your own "garbage collector" that cleans up dangling symlinks in your home directory. 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 https://linux.die.net/man/8/stow

cipherboy 6y ago

> and delete it another way in another place (git rm). I use `rm` all the time in git repos... Just `git add` when it is time to stage changes.

ironmagma 6y ago
Right, but when you unlink it from your home directory, the file still exists in the git repo. So there is a manual synchronization that must happen between the two directories.
- coldtea 6y ago
  >Right, but when you unlink it from your home directory, the file still exists in the git repo. That's a feature.
  - ironmagma 6y ago
    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.
    - Galanwe 6y ago
      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.
    - kelnos 6y ago
      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.
  - macintux 6y ago
    `git rm` will still leave the file available in the repo history, so violating the consistency seems more like a bug than a feature.
    - coldtea 6y ago
      Still a feature. You might want to revert back to it. And history is history.

ljm 6y ago

If all your configs follow the XDG spec then you can turn ~/.config itself into the repo,and then use .gitignore as a whitelist: /* !git/config !tmux/tmux.conf I do this and clone my repo directly to .config on a new machine. The only hold out was tmux but that's solved by installing or compiling one of the recent versions released this year (3b/3c). I'll still use manual symlinks for things like bash, but they're outliers. Works great for me.

midchildan 6y ago

I believe Stow can fix everything except #2 [1], although I haven't actually used it before. But it's also easy to create your own "garbage collector" that cleans up dangling symlinks in your home directory. 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 https://linux.die.net/man/8/stow