Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Using GNU Stow to manage your dotfiles (2012)

brandon.invergo.net

Post reply on HN
Print view View original

101–110 of 116 posts

Re: Using GNU Stow to manage your dotfiles (2012)

#101

Post by adamspiers »

bbkane wrote: post #69
rubyist5eva wrote: post #39

Earlier quoted context omitted.

Stow does this, it also has a --dotfiles switch so you can save your files as `dot-vimrc`, `dot-bashrc`, etc... so you don't have a bunch of hidden files in your repo

Too bad that's broken for directory names: https://github.com/aspiers/stow/issues/33

Stow maintainer here. Thanks for the nudge on that, and apologies for not doing a better job. I hadn't noticed that this issue affecting so many users. I have some downtime in the coming week or two so will look at this.

Re: Using GNU Stow to manage your dotfiles (2012)

#102

Post by sooheon »

e40 wrote: post #83
devy wrote: post #72

Earlier quoted context omitted.

> but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? Nothing wrong with tracking dotfiles with Git. It's probably the simplest and easiest approach without requiring any fancy tools other than Git. However, as mentioned in ArchLinux's wiki page, the disadvantage of Git approach is that "host-specific configuration generall…

I've had my dotfiles in git for 7+ years. Work on Windows, Linux and macOS. Conditionalization in BASH is dead simple. EDIT: 12+ years at work.

Yeah, it seems like keeping the cond inside the dotfiles, rather than in a dotfiles manager is the way to go.

Re: Using GNU Stow to manage your dotfiles (2012)

#103

Post by adamcstephens »

leipert wrote: post #18

I like dotbot [0] and have been using it for a while. How do people manage secrets, I am encrypting with keybase, but really want to move away from it. [0]: https://github.com/anishathalye/dotbot

I use dotbot as well, after having used fresh for many years. It took me a while to unwind the shell logic I’d build into fresh but I prefer dotbots yaml config.

I have a strict no secrets policy and they get laid down manually on any system that needs them.

Re: Using GNU Stow to manage your dotfiles (2012)

#104

Post by tpoacher »

tambourine_man wrote: post #63
nickjj wrote: post #29

Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? If you wanted to you could && a few symlinks and other commands into 1 copy / paste'able command to get up and running really quickly. It's also painless to manage secrets by sourcing in optional files. It also works nicely when you want files living…

I still remember when git was the hot new version control system, so old fashioned sounds funny to me.

I had the same reaction. Stow was first released (v>1.0) in 1996, git in 2013. Yet git is the old-fashioned choice? hahah.

Re: Using GNU Stow to manage your dotfiles (2012)

#105

Post by tpoacher »

Sounds interesting, but I can't help but wonder:

> all your dotfiles are now neatly organised

isn't that what .config is for?

> install locally built packages in /usr/local/stow/PKGNAME-VERSION [...] so you don’t have to worry about any stray files

Isn't that what /opt is for?

> (HN comments live-linking to a repository)

So maintain externally and export as needed.

... am I missing some really important context here? I downloaded stow to check it out, but the whole 'dotfile/installation' use-case in the article sounds like a nothingburger to me.

Re: Using GNU Stow to manage your dotfiles (2012)

#106

Post by podiki »

bambambazooka wrote: post #75
podiki wrote: post #19

STOW is great, it is simple and works well especially combined with git. That's what I do [0], and recently combined it with org-mode for literate programming, so each program has just a README.org that then generates all the files via org tangle [1] [2]. For example, here is my file that generates my Xorg configuration [3] over several files, nicely readable on GitHub, in Emacs, or just as plain text. [0] https://gi…

I really like the idea! Thanks for mentioning it. I thought about converting my dotfiles to org-mode files but managing the tangling is always the step where I stop. I think I'd rather automate the tangling. I see you commit the tangled "results". Is this by choice or is it a compromise?

I commit the tangled results so that I can use Stow directly on other computers. But this could be easily automated with a script (since you can tangle without opening emacs directly, or within the org file itself!) to tangle after any update, or even to pull in changes if you make them to the file directly. For example, you could have a hook so that on saving the org file it tangles to update any files, or on opening pull in changes you made directly in the result file (e.g. not in the org file directly). I saw some links on this but unfortunately don't have them handy. I'm sure they will come up with some searching, but let me know if you can't find anything.

Re: Using GNU Stow to manage your dotfiles (2012)

#107

Post by devy »

sooheon wrote: post #102
e40 wrote: post #83

Earlier quoted context omitted.

I've had my dotfiles in git for 7+ years. Work on Windows, Linux and macOS. Conditionalization in BASH is dead simple. EDIT: 12+ years at work.

Yeah, it seems like keeping the cond inside the dotfiles, rather than in a dotfiles manager is the way to go.

Can you share some of your setup there to exemplify? Thanks.

Re: Using GNU Stow to manage your dotfiles (2012)

#108

Post by e40 »

devy wrote: post #107
sooheon wrote: post #102

Earlier quoted context omitted.

Yeah, it seems like keeping the cond inside the dotfiles, rather than in a dotfiles manager is the way to go.

Can you share some of your setup there to exemplify? Thanks.

I use $(uname -s) (Cygwin required on Windows) and dispatch on that. There's really nothing more than that.

Re: Using GNU Stow to manage your dotfiles (2012)

#109

Post by codethief »

larusso wrote: post #82
wwright wrote: post #74

Earlier quoted context omitted.

Have you played with NixOS or Guix at all? They attempt to solve this problem from the ground up for the entire OS. It obviously has trade offs, but IMO it is the best solution around today (other than Kubernetes, but that is an abstraction level higher).

I really love nix and nixOS and I‘m also using homemanager on my macOS machine and an WSL instance. But I decided to turn away from it. Using just the nix packagemanager on a distribution feels off and doesn’t bring you all the benefits. On macOS it can be very frustrating to find a programm that is in the mix packages but not available for macOS. Plus some tools tend to be very outdated and use very general compile…

Thanks, I was entertaining the idea of giving nixOS a try for managing my dotfiles but your post confirms my suspicions!

Re: Using GNU Stow to manage your dotfiles (2012)

#110

Post by JoshTriplett »

yesbabyyes wrote: post #77
JoshTriplett wrote: post #67

Earlier quoted context omitted.

> Call me old fashioned but what's wrong with having a regular git repo anywhere you want with all of your dotfiles and them symlink those files to where they need to go? I prefer to skip the symlinks, and just directly use the git repository as my home directory. (I have a sizable .gitignore for things I don't want to track.)

I do the same, but I just have a single '*' in my .gitignore. The only drawback to the homedir-as-git-repo approach I've found is that you're always in a git repo, so you have to be careful not adding stuff which was really supposed to go in another repo.

> The only drawback to the homedir-as-git-repo approach I've found is that you're always in a git repo, so you have to be careful not adding stuff which was really supposed to go in another repo.

I tend to always run "git status" before adding anything, which makes it fairly obvious what repository I'm in. (Or I'm working via fugitive in vim, which helps in the same way.)

Post reply on HN