Live data from Hacker News

Using GNU Stow to manage your dotfiles

brandon.invergo.net

51–60 of 73 posts

Re: Using GNU Stow to manage your dotfiles

#51
post #33

Earlier quoted context omitted.

WAT. Are you trolling us, or are you that uninformed about VCS history? Giving you the benefit of the doubt, just learn and use git[1]. Yes, there are things about the UI that suck. But the underlying machinery and power it provides is unparalleled. RCS, in short, is that horrible feet-killing pair of boots that made you think you hated , when in fact it was just frustration with sub-par equipment. [1] If you need to…

Ha! Fair enough. No, I didn't intend to troll. I've found RCS useful for ad hoc versioning of configuration files on systems without git or other version control systems. Wondering whether anyone still finds it useful. I reckon not!

RCS is a lot less complexity and remembering commands than a full-on VCS for a few stray config files.

Re: Using GNU Stow to manage your dotfiles

#52
post #33

Earlier quoted context omitted.

WAT. Are you trolling us, or are you that uninformed about VCS history? Giving you the benefit of the doubt, just learn and use git[1]. Yes, there are things about the UI that suck. But the underlying machinery and power it provides is unparalleled. RCS, in short, is that horrible feet-killing pair of boots that made you think you hated , when in fact it was just frustration with sub-par equipment. [1] If you need to…

Ha! Fair enough. No, I didn't intend to troll. I've found RCS useful for ad hoc versioning of configuration files on systems without git or other version control systems. Wondering whether anyone still finds it useful. I reckon not!

I've recently installed RCS on a Windows host for versioning my .emacs file, and I rely on Emacs VC to drive the tool.

On Solaris hosts, including locked-down "production", I use SCCS to version my dot-files because it's available by default. For development I use SVN (old too by today's standards).

I don't advocate using these old tools over modern alternatives; however I find their simplicity in the above cases to be beneficial.

Re: Using GNU Stow to manage your dotfiles

#53
post #9
post #2

but many/most dotfiles reside at the top-level of your home directory, where it wouldn't be a good idea to initialize a VCS repository I totally disagree. I love having much of my home directory in git. I have a .gitiignore for the stuff I don't want in there, but the rest. Ahhhhh, so nice to be able to clone somewhere else and use.

I also keep my whole homedir in git, and it's great. My approach isn't to .gitignore, because I want to ignore almost everything -- I just add and commit things when I want to track them. One of my many git aliases[1] is 'git sn' for showing status without untracked files; this helps when dealing with my homedir: status --short --branch --untracked=no [1] https://github.com/cespare/dotfiles/blob/master/.gitconfig#L..…

I wondered about this, but I pose this question to you: what happens if you have a merge problem with, say, a libreoffice doc or something. How do you handle that? I use hg, but I imagine my plight would be similar. TIA.

Re: Using GNU Stow to manage your dotfiles

#54
just for completeness sake and because no one mentioned it yet: https://github.com/technicalpickles/homesick

yes, you need ruby for it but I dont really see that as a problem. Its a bit confusing at first (could be just me, but I still dont get why you have basically 2 repos, one managed by homesick and the one you checked out yourself) but it works fairly well. Takes care of symlinking, updating and whatever you want.

Re: Using GNU Stow to manage your dotfiles

#55
> I've come across various programs which aim to manage this for you by keeping all the files in a subdirectory and then installing or linking them into their appropriate places. None of those programs ever really appealed to me. They would require a ton of dependencies (like Ruby and a ton of libraries for it) or they would require me to remember how to use them, which is difficult when really for such a task you rarely use the program.

Ever heard of shell scripts? This is what I use: https://code.google.com/p/aram-dotfiles/source/browse/make.u...

Re: Using GNU Stow to manage your dotfiles

#56
post #40

I've made my own similar solution. I have all mine on Github, so I git clone the repo, and run my bootstrap script, which initializes the submodules, Vundle's all my vim plugins, and symlinks all the files. https://github.com/Aaronneyer/dotfiles

isn't that sort of info kinda sensitive https://github.com/Aaronneyer/dotfiles/blob/master/sshconfig ? I can see hosts and usernames...

Ya, that's actually something I've been meaning to pull out, although I don't think it really matters all that much if people know what hosts/usernames I have.

Re: Using GNU Stow to manage your dotfiles

#58

I'm using a bash script [0] too, it is bit complicated because of I've have three different workplaces and some conf files that have account information (such as email passwords) should be hidden. [0] https://github.com/seletskiy/dotfiles/blob/master/dotfiles.s...

I "solved" that problem by having two repositories: dotfiles & dotfiles-private.

The public repository has .bashrc, etc in it. The private repository has ~/.mutt/work-muttrc, etc in it.

Re: Using GNU Stow to manage your dotfiles

#59
post #50
post #2

but many/most dotfiles reside at the top-level of your home directory, where it wouldn't be a good idea to initialize a VCS repository I totally disagree. I love having much of my home directory in git. I have a .gitiignore for the stuff I don't want in there, but the rest. Ahhhhh, so nice to be able to clone somewhere else and use.

Be careful, this is how devs expose private ssh keys.

I push it to a local git repo that has the same perms as my account and .ssh directory. But, I agree. You need to be careful.

Re: Using GNU Stow to manage your dotfiles

#60
post #13

I would really like to have a dotfile strategy. But I have another goal beyond synchronization: I would like to be able to organize my dotfiles in a modular fashion. For example, I would like to construct my bashrc using something like run-parts. This system would take bash/★.bashrc, this-machine/local-env.bashrc, and special-app/proxy-env.bashrc and compile them into a single ~/.bashrc. I would also like to be able…

I hae something like this in my ~/.bashrc file:

    for i in ~/.bash.d/* ~/.local.bash.d/; do
         test -e $i && source $i
    done
Which functionally does what you want, loading everything from a directory. Though it doesn't do version-testing, or actual concatenation.
Post reply on HN