Show HN: A way to manage dotfiles without silly symlinks and special tools
1–7 of 7 posts
Re: Show HN: A way to manage dotfiles without silly symlinks and special tools
#2Man, symlinks are not silly, they are super easy to deal with and super powerful. They do everything for you without you even knowing it.
Now, you're using Git submodules in your setup. This, yes, is a nasty and dangerous thing to deal with.
Re: Show HN: A way to manage dotfiles without silly symlinks and special tools
#3not too happy about having $HOME as a git repo... but I have to say, it's a clever solution. I will probably stick to symlinks though. They are not silly, they are actually extremely useful if you know how to use them.
Re: Show HN: A way to manage dotfiles without silly symlinks and special tools
#4Man, symlinks are not silly, they are super easy to deal with and super powerful. They do everything for you without you even knowing it. Now, you're using Git submodules in your setup. This, yes, is a nasty and dangerous thing to deal with.
erm, firstly, by silly symlinks I meant in the context of managing dotfiles. A lot of exiting tools do that and IMHO, it is silly. Of course in yours it might make perfect sense. Secondly, erm -- git submodules are nasty and dangerous ? ...for managing vim files ? How am I to use pathogen (or all the hipsters to use oh-my-)). I didn't say this is what you use on your production servers. This is how I manage my dotfiles on my personal boxes and find it easier to use than any specific purpose tool.
Re: Show HN: A way to manage dotfiles without silly symlinks and special tools
#5not too happy about having $HOME as a git repo... but I have to say, it's a clever solution. I will probably stick to symlinks though. They are not silly, they are actually extremely useful if you know how to use them.
Any specific reason why $HOME is not good for a git repo in this specific case ? AFAICT, the repo is tracking only what is mentioned in the .gitignore.
As for symlinks, heh, yes I do know they are not silly and actually extremely useful and yes I know how to use them. I simply think they are silly for managing dotfiles. If your intent is to version your dotfiles and have different 'profiles' across your systems, using the tools at hand -- well, in theory you can write a bunch of script to create the symlinks and 'manage' them as well -- but I just find /that/ silly.
Re: Show HN: A way to manage dotfiles without silly symlinks and special tools
#6not too happy about having $HOME as a git repo... but I have to say, it's a clever solution. I will probably stick to symlinks though. They are not silly, they are actually extremely useful if you know how to use them.
Any specific reason why $HOME is not good for a git repo in this specific case ? AFAICT, the repo is tracking only what is mentioned in the .gitignore. As for symlinks, heh, yes I do know they are not silly and actually extremely useful and yes I know how to use them. I simply think they are silly for managing dotfiles. If your intent is to version your dotfiles and have different 'profiles' across your systems, usin…
just the fact that it feels _unnatural_. I'm not saying it's wrong, just that personally I don't feel it's a good thing. I know it's tracking only the things you add to it, but still. I think my problem with it is that it feels messy.
My approach: git repo with a very simple setup script that creates symlinks to the dotfiles/dotdirs. It also manages some sensitive things like gpg/ssh keys.
Re: Show HN: A way to manage dotfiles without silly symlinks and special tools
#7Earlier quoted context omitted.
Any specific reason why $HOME is not good for a git repo in this specific case ? AFAICT, the repo is tracking only what is mentioned in the .gitignore. As for symlinks, heh, yes I do know they are not silly and actually extremely useful and yes I know how to use them. I simply think they are silly for managing dotfiles. If your intent is to version your dotfiles and have different 'profiles' across your systems, usin…
just the fact that it feels _unnatural_. I'm not saying it's wrong, just that personally I don't feel it's a good thing. I know it's tracking only the things you add to it, but still. I think my problem with it is that it feels messy. My approach: git repo with a very simple setup script that creates symlinks to the dotfiles/dotdirs. It also manages some sensitive things like gpg/ssh keys.
Yeah, in some way it's something the VCS are lacking right now: being able to add files outside the .git/ parent directory, so you can index a given directory in multiple working trees/repositories.
So you can have a ~/dotfiles working tree that points to ~. And perhaps a ~/mydata working tree that points to ~ as well. Both will index different files as manually added by the user.