[HN Gopher] Using GNU Stow to manage your dotfiles (2012)
       ___________________________________________________________________
        
       Using GNU Stow to manage your dotfiles (2012)
        
       Author : marcinreal
       Score  : 48 points
       Date   : 2022-07-27 16:59 UTC (6 hours ago)
        
 (HTM) web link (brandon.invergo.net)
 (TXT) w3m dump (brandon.invergo.net)
        
       | blueflow wrote:
       | Track you ~/.config (or whatever your XDG_CONFIG_HOME is)
       | directory in git, and create symlinks for those programs that
       | don't look there, optionally by script. Many programs already use
       | that directory to store their configs. The Arch Linux folks are
       | nagging every upstream into supporting it[1]. Also it requires no
       | extra dependency aside git.
       | 
       | I think i say this everytime a dotfiles manager comes up.
       | 
       | [1] https://wiki.archlinux.org/title/XDG_Base_Directory
        
         | lambdaba wrote:
         | I take the opposite approach in that I keep the default config
         | file locations and have .gitignore set to "*", and just force-
         | add files as needed. Also have GIT_DIR and GIT_WORK_TREE=$HOME
        
         | hiq wrote:
         | This sounds like a good idea, I'd save all the `ln` commands
         | the install.sh of my dotfiles repo. But do you just .gitignore
         | all stuff in your .config you're not interested in?
        
           | blueflow wrote:
           | I used to have some ignored, but nowadays i live with the
           | files showing up as untracked.
        
       | canistel wrote:
       | I have to admit, sheepishly, that I use RCS for version
       | controlling dot files and even files such as fstab and grub. I
       | use it in Windows too.
       | 
       | Infrequently, even on binary files (smirk).
       | 
       | There, I have said it, and taken the load off my conscience...
        
         | mek6800d2 wrote:
         | A load off my mind too -- I now know there at least two of us
         | in the world! :)
        
       | simjue wrote:
       | Shameless self-plug: I could never get along with storing the
       | whole content of the dotfiles when I casually just added a few
       | lines I cared about, so I developed my own tool called confible.
       | You can specify to just append a few lines or add the whole
       | config and it can run commands (e.g. installing the specific tool
       | together with its config). You can find it at
       | https://github.com/sj14/confible
        
         | heyoni wrote:
         | That's pretty cool. The dumbed down version of that for me is
         | sourcing different zshrc files depending on the machine I'm
         | using...which obviously wouldn't work for anything else.
        
       | romeoblade wrote:
       | I started using fossil for this very thing. I was using git,
       | however I like that fossil allows you to put the repository where
       | ever you want on the file system. I don't have to worry about
       | alias's, using .gitignore, or setting it it up where it doesn't
       | show untracked files.
       | 
       | As far as fossil is concerned, once you close the repo, it's out
       | of site of mind. I still use git for most everything else. Only
       | my dot files and my personal obsidian vaults are backed up to
       | fossil.
        
         | masklinn wrote:
         | Could you explain further? Because
         | 
         | > I was using git, however I like that fossil allows you to put
         | the repository where ever you want on the file system. I don't
         | have to worry about alias's, using .gitignore, or setting it it
         | up where it doesn't show untracked files.
         | 
         | Git also lets you put the repository wherever you want on the
         | filesystem, via worktrees or via the `--separate` link. And I
         | fail to see the relationship with aliases or ignore files (the
         | last item I guess you're talking about fossil not showing
         | untracked files by default?)
        
           | romeoblade wrote:
           | Sure (Sorry was mobile earlier, normally my grammar isn't
           | that bad.)
           | 
           | Fossil doesn't show much unless you perform a open or a
           | checkout against the repo file. Generally, it only shows the
           | location of the config database ($HOME or $XDG) _exmaples
           | below_. The added benefit is that you can do this open
           | /checkout anywhere on the system. For instance, if I'm making
           | changes in my /etc, I can commit a file from there without
           | having to move the file. Another nice feature is they have an
           | unversioned [1] mechanism as well, which allows you to commit
           | files that you want to save but don't care about the history.
           | Ran from my $HOME       -------------------------       $
           | fossil info       config-db:
           | /home/$USERNAME/.config/fossil.db       fossil:
           | /home/$USERNAME/.local/bin/fossil       version:      2.19
           | [1e131febd3] 2022-07-21 16:10:55 UTC            $ fossil
           | status       current directory is not within an open checkout
           | --------------------------
           | 
           | I still prefer git, and all my career and personal projects
           | reside there. But every tool has its place, and I think that
           | even though fossil doesn't fit my other SCM needs. What I'm
           | using it for is perfect for fossils design.
           | 
           | Used several times to back up some critical configurations
           | (3rd/4th paranoia backup right before maintenance) on a few
           | servers because the commit/open from anywhere. It doesn't
           | pollute the file system as it's a single file.
           | 
           | With the untracked files: It's a little different. The git
           | way you usually use do the dot file backup is with an alias
           | `--untracked-files=no` so you don't see them unless you
           | override it. At least most of the examples I followed the
           | processes I've experimented with over the years recommended.
           | 
           | With fossil you see them when you consciously issue a fossil
           | open in order to do a commit. I'd rather see the untracked
           | files, when I'm ready to commit then to not see them at all
           | and miss something. Out of site. out of mind is something I
           | personally struggle with.
           | 
           | [1] https://fossil-scm.org/home/help/uv
           | 
           | * Edited for formatting.
        
         | cssanchez wrote:
         | Do you use a cloud host like Github for Fossil?
        
           | romeoblade wrote:
           | I have a small digital ocean droplet, lowest tier serving
           | mine. I need to probably do a write up of the steps soon
           | before I forget. I'ts its own web server so you have a lot of
           | options. SCGI, HTTPS, SSH, Socket Listener. I have mine
           | behind reverse proxy sand boxed with systemd's DynamicUsers
           | feature.
        
           | thunderbong wrote:
           | If you have fossil installed on a server which is always on,
           | you already have it!
           | 
           | Otherwise, you can always use chisel [0]
           | 
           | [0]: https://chiselapp.com
        
       | vinceguidry wrote:
       | I wound up writing my own stow replacement in Ruby, that moved
       | the files rather than symlinked them. It does pattern-match the
       | filenames with a list, anything on the list gets symlinked. It
       | can also copy home-rolled binaries into /usr/local/bin. I suppose
       | I could use both stow and etckeeper but a simple script can keep
       | everything synced to my precise liking.
        
       | dang wrote:
       | Related:
       | 
       |  _Using GNU Stow to manage your dotfiles (2012)_ -
       | https://news.ycombinator.com/item?id=25549462 - Dec 2020 (113
       | comments)
       | 
       |  _Using GNU Stow to manage dotfiles (2013)_ -
       | https://news.ycombinator.com/item?id=15196141 - Sept 2017 (24
       | comments)
       | 
       |  _Using GNU Stow to manage your dotfiles_ -
       | https://news.ycombinator.com/item?id=8487840 - Oct 2014 (68
       | comments)
       | 
       |  _Using GNU Stow to manage your dotfiles_ -
       | https://news.ycombinator.com/item?id=6331485 - Sept 2013 (69
       | comments)
        
       | hoosieree wrote:
       | Huh, I guess I implemented something like stow for myself without
       | realizing it.
       | 
       | I keep my dotfiles in a private git repo, and in that repo is a
       | shell script that creates symlinks (or creates folders with
       | symlinks inside).
       | 
       | Paths are hard-coded in the shell script, but that actually
       | reduces my cognitive load.
        
         | clktmr wrote:
         | I'm doing the same:
         | 
         | https://gist.github.com/clktmr/7343895cc0dcc5a80a6c3d39d22ca...
         | 
         | This will also backup and restore any files it might override.
        
       | jasonpeacock wrote:
       | There's also `homesick`[1], which is a Ruby dotfile manager. If
       | you don't feel like managing a Ruby distro and want something
       | more portable (and `homesick` looks to be a stale project
       | anyway), you can use `homeshick`[2] which is a Bash port that's
       | still being maintained. (I use `homeshick`)
       | 
       | The last time I dug into this, `homeshick` was had more features
       | and fit my needs better than `stow`.
       | 
       | Alternatively, check out YADM[3], "Yet Another Dotfile Manager",
       | which I'm probably switching to once I get some time.
       | 
       | [1] https://github.com/technicalpickles/homesick
       | 
       | [2] https://github.com/andsens/homeshick
       | 
       | [3] https://yadm.io/
        
       | politelemon wrote:
       | It feels unsafe to store dot files in source control as the
       | article mentions. Is this a common practice? They could contain
       | sensitive information and I fear people might be tempted to push
       | to GitHub.
       | 
       | What about storing such files in a password manager/database?
        
         | lvass wrote:
         | >contain sensitive information and I fear people might be
         | tempted to push to GitHub
         | 
         | Nothing can really protect someone from this level of insanity.
        
           | politelemon wrote:
           | Anecdotal, I encounter it quite often at work among 'newer'
           | developers, who have been doing this ever since Github
           | private repos went free! That's why my question. Thanks for
           | the answers everyone, it does come down to diligence and
           | knowing what you're doing.
        
         | yoyohello13 wrote:
         | Many people have their dotfiles up on GitHub. As long as you're
         | aware of what is in your dotfiles it pretty benign. Just put
         | your passwords elsewhere.
        
         | layer8 wrote:
         | There are a number of possible solutions:
         | 
         | git-remote-gcrypt: https://github.com/spwhitton/git-remote-
         | gcrypt
         | 
         | git-crypt: https://github.com/AGWA/git-crypt
         | 
         | git-secret: https://github.com/sobolevn/git-secret
         | 
         | However, most people who self-host their Git repository are
         | fine with just transport-level encryption (TLS).
        
         | marcinreal wrote:
         | Just don't push to GitHub. :) You can also pick and choose what
         | you want in the repos with this method. It's a very useful
         | technique for tracking and rolling back changes to dotfiles
         | that you care about. You can even make backups of the directory
         | which can help you bootstrap new machines really quick.
         | 
         | In a similar vein, I also have a git repo containing my todo
         | list, journal, etc. and review and commit the changes once a
         | week. Very helpful for catching accidental
         | deletions/modifications. I have never been tempted to push
         | these repos.
        
         | aidenn0 wrote:
         | There are plenty of tools to manage secrets in VCS, so that's
         | always an option. As an aside, _most_ programs now have a
         | method to move sensitive information outside of the
         | configuration file, so you can minimize what ends up in there.
        
       | milicat wrote:
       | Interesting. I'd consider it, if I wasn't already on NixOS with
       | home-manager.
        
         | surrTurr wrote:
         | Are you using NixOS as your main desktop?
        
           | jphsnsir wrote:
           | Yes
        
         | JamesSwift wrote:
         | Stow was a good stepping stone before I adopted nix + home-
         | manager. Its more effort to learn overall but also a much
         | cleaner/stronger approach IMO.
        
       | j1elo wrote:
       | It's 2022 and I still use this program since I read that article
       | so many years ago.
       | 
       | It's handy but sometimes a bit of manual preparation must be done
       | on a new clean machine. For example if you want to stow only some
       | files under ~/.config/program/ and not the whole program/
       | directory, you must first run an mkdir and _then_ run stow to put
       | the appropriate symlinks in place.
        
         | lasftew wrote:
         | Use the --no-folding flag to prevent stow from linking
         | directories.
        
         | heyoni wrote:
         | I use this too but every other time I come back to it I have to
         | really read through the docs to figure stuff out. That's just
         | me not writing very useful notes though -_-
        
           | marcinreal wrote:
           | When I did the setup I kept the commands I used in a
           | Makefile. In theory, running `make` should do all the setup
           | for me on a new machine.
        
       | pilcha wrote:
       | After trying a bunch of tools I settled on git-tracking $HOME
       | with '*' on my .gitignore (ignores everything, you have to add
       | new files by --force). Is this better? symlinks seem like a
       | smell.
        
         | marcinreal wrote:
         | I didn't know about the --force flag. You can also whitelist
         | files in .gitignore with !filename.[0]
         | 
         | Is there a reason to avoid symlinks? I've been using this setup
         | for a few years now, (using an artisanal, home-rolled script
         | before I discovered stow) and it's worked superbly.
         | 
         | [0]: https://monkeyfacts.io/git-whitelist-directory-subfiles/
        
           | lambdaba wrote:
           | Symlinks can be broken, so if you can avoid them altogether
           | why not? It's just an extra if tiny bit of complexity
        
       | smm11 wrote:
       | rsync dot files to wherever.
        
         | 5e92cb50239222b wrote:
         | ... and lose change history, handle merge conflicts by yourself
         | (or lose edits made on other systems if you ever forget to re-
         | sync), and all the other features of a proper VCS.
        
           | heyoni wrote:
           | These comments are like that famous one where dropbox was
           | announced on HN and someone replied to it with an rsync
           | script "that is essentially the same".
           | 
           | What's it called when people do that?
        
             | politelemon wrote:
             | Pooh-poohing?
             | 
             | Dismissiveness?
             | 
             | Being an HNer?
        
           | marcinreal wrote:
           | Hah, I recently had to setup a cronjob that rsync's my org-
           | mode files to iCloud. (iCloud didn't work with symlinks, but
           | I needed to somehow sync my org-mode files to my phone.)
           | Anyway, my org directory happens to be a git repo, and I
           | rsync the whole repo including .git, so that's technically
           | something you can do. :)
        
       | neeasade wrote:
       | Been doing this for about a decade, it works nicely. Def
       | recommend stows `--no-folding` flag (which prevents it from
       | symlinking directories, just files)
       | 
       | obligatory vanity link: http://noriceno.life
        
       | AndrewVos wrote:
       | I use my own tool for this: https://github.com/AndrewVos/pj
        
       | 5e92cb50239222b wrote:
       | I very much prefer this simple method:
       | 
       | https://www.atlassian.com/git/tutorials/dotfiles
       | 
       | tl;dr: it puts the .git directory aside and lets you use it to
       | store any files on your filesystem.
       | 
       | All the usual commands work, except you use something like
       | `config` or `dofiles` instead of `git`:                 $ config
       | add ~/.config       $ config commit -m initial\ commit
       | 
       | It's pretty much the same as creating a git repository in /, but
       | doesn't mess with your normal git usage (so if you run `git
       | status` in `/home/foo/src/my-awesome-project` and git repository
       | has not been created there yet, git will fail with "not a git
       | repository" and won't show you the contents of your whole
       | filesystem tree).
        
         | politelemon wrote:
         | Thanks for sharing that. Question, where do you normally push
         | the "repo" to?
        
           | bryankaplan wrote:
           | I'm not the person you asked, but it's trivial to host your
           | own git repos on a server.
        
           | 5e92cb50239222b wrote:
           | Doesn't matter in my case, there are no secrets there (so I
           | use a public git forge). If this doesn't work for you, you
           | can just push to any old server via ssh:                 $
           | git remote add foobar address:path/relative/to/home/dir
           | $ git push foobar
           | 
           | , or self-host Gitea with registration closed if you want a
           | proper forge.
        
         | lvass wrote:
         | >if you run `git status`
         | 
         | Is this a problem if you gitignore * (whitelisting)?
        
           | 5e92cb50239222b wrote:
           | I used this initially (before running into the link above),
           | but it still requires using a 'global' git repository which
           | had its share of issues (some build scripts didn't like it,
           | for example).
        
         | publicdaniel wrote:
         | This is what I do, it has worked great for me. The only
         | annoying thing is I can't get tab completing to work in my
         | shell (ZSH). Something about the alias I think.
        
       ___________________________________________________________________
       (page generated 2022-07-27 23:02 UTC)