4 ms·

"dotfiles managers" are over-engineered waste of time. You only need git. Create ~/.gitignore with a single line: * git tracks modifications to your dotfi

"dotfiles managers" are over-engineered waste of time. You only need git. Create ~/.gitignore with a single line: * git tracks modifications to your dotfiles. And on the rare occasion that you need to add a new file, just force-add it: git add -f ~/.foorc If you need a script to "install" your dotfiles, you're doing it wrong.

jiiam 11y ago
This seems like an astonishingly good idea. It maybe lacks features for my home computer, but would be good for throw away servers like those you get from DigitalOcean, where I systematically set up everything over and over again each time.
corndoge 11y ago
I fail to see how this comes with the convenience of directory-specific symbolic links, dotfile-specific backups, individual removal & replacement of dotfiles, etc etc. I've been using stow for years to manage my dotfiles and it's never been more involved than $ stow dotfiles/urxvt or what have you. In fact I would say that managing a git repository is more of a waste of time and far more over-engineered for a task easily solved by a tiny binary. Not sure what you're referring to by an 'install script', have you ever used stow? In any case, the real answer is that you should be using whatever works best for your use case, and for me that's stow.
- pmoriarty 11y ago
  That does not work for me. When I try "stow foo/bar" I get this error: Undefined subroutine &main::error called at /usr/bin/stow line 568, <DATA> line 18. where line 568 of /usr/bin/stow is: error("Slashes are not permitted in package names"); What version of stow do you have? I'm using stow 2.2.0-r2 on Gentoo Linux.
  - dbbolton 11y ago
    From the documentation page: >A package directory is the root of a tree containing the installation image for a particular package. Each package directory must reside in a stow directory — e.g., the package directory /usr/local/stow/perl must reside in the stow directory /usr/local/stow. The name of a package is the name of its directory within the stow directory — e.g., perl. https://www.gnu.org/software/stow/manual/stow.html https://www.gnu.org/software/stow/manual/stow.html The article in the OP also doesn't use this format. Instead it's prefaced with a `cd` command, so you would need to do: cd foo; stow bar
  - corndoge 10y ago
    I use xstow, which permits slashes; usually I do just cd into the dotfiles directory and stow out from there (otherwise you need to specify a target directory) but I left that part out for brevity.
tomphoolery 11y ago
I made a script which makes that kind of thing easier to manage: https://github.com/tubbo/homer https://github.com/tubbo/homer
Pirate-of-SV 11y ago
That's a really nice solution actually, letting git do the magic. I'm definitely gonna try it. At the moment I use a python install script that backup already existing files and set up the symlinks.
saulrh 11y ago
I did this for a while. I had to switch to stow when I got a new job that had data security requirements - I had to keep the "work" bits of my dotfiles separate from the non-work parts, and so couldn't keep everything in the same git repository. Ended up writing a set of rcs that just imported appropriate .d directories, keeping two git repos, and stowing both of them.
sciencerobot 11y ago
I tried this but git uses ~/.git for any subdirectory of $HOME. For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository. It's easy to undo but still kind of annoying.
- nebulous1 11y ago
  You can add export GIT_CEILING_DIRECTORIES=~ to your .bashrc (or equivalent)
- justinmk 11y ago
  > For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository. If your project has its own .git directory, no, it won't add to ~/.git.
  - sciencerobot 10y ago
    You're right. I forgot to mention that this only happens if you haven't initiated a new git repository in the directory you're working in.
noctuid 11y ago
I agree. I looked at quite a few dotfile managers, and all of them were overly complicated and couldn't replace my use of stow. Stow was not created as a "dotfiles manager" though, and keeping dotfiles seperate from all the other crud under ~/ is a lot cleaner in my opinion. I don't want my home directory to be a git repo either.
avar 11y ago
I do pretty much this but I have public dotfiles (on github), then an overlay for work files so I need a script to maintain those symlinks, and then work ones that I don't share with coworkers (contain private passwords). So I have a script that manages the symlinks for multiple such repos, knows to remove the broken links as needed, and I have something I can just paste into the terminal of any machine and it'll set that box up with my public/work/private dotfiles as appropriate. It's not perfect, but it works, just pointing out that even for relatively simple cases having a dotfile manager (or writing your own) can make sense.
- weinzierl 11y ago
  I still resolve the "overlay for work files" situation manually. Would you care to share your script?
  - avar 10y ago
    Okey, but prepere for some super-lame ad-hoc code. Also I was misremembering about it handling multiple repos, in the one place where I have >1 I just do that manually. My .bashrc will run a bootstrap_work_dotfiles function when bash starts: https://github.com/avar/dotfiles/blob/master/.bashrc#L410 https://github.com/avar/dotfiles/blob/master/.bashrc#L410 This then clones my ~/g/avar-dotfiles-work repo if I'm at work and it hasn't been cloned: https://github.com/avar/dotfiles/blob/master/.bashrc#L355 https://github.com/avar/dotfiles/blob/master/.bashrc#L355 I have a "dud" function (dotfile update) function that'll update both, it basically does a git pull, re-chmods ~/.ssh/config: https://github.com/avar/dotfiles/blob/master/.bashrc#L381 https://github.com/avar/dotfiles/blob/master/.bashrc#L381 And also, and what you asked for, removes any stale symlinks via this one-liner: https://github.com/avar/dotfiles/blob/master/.bashrc#L348 https://github.com/avar/dotfiles/blob/master/.bashrc#L348 Basically doing a find on my ~ directory and finding any broken links pointing to the known location of the overlay repo. I see now that there's a potential bug in it where it narrows its search in such a way that it could miss it if you add/remove new ~/.??* files. This could be solved, but I have it like that because I only ever add/remove stuff in e.g. ~/.bashrc.d/ or ~/.screenrc.d/, so this way the find takes less time to run. Then I have a generated one-liner that I can paste into new machines that clones my dotfiles.git into ~/g/, moves the .git to ~/, then sources bashrc which bootstraps the rest.
hk__2 11y ago
I don’t want to have a Git repository in my $HOME; I prefer to have it somewhere else correctly organized then symlink everything.
- tgamblin 11y ago
  I manage my dotfiles in a separate git repo in ~/.dotfiles, and I have simple scripts that link and unlink everything. It's worked well for me for quite some time: https://github.com/tgamblin/dotfiles https://github.com/tgamblin/dotfiles
lolidaisuki 11y ago
With stow you can have just one git repo for all of your dotfiles instead of one per host if there are differences. Then you can just install the host specific dotfiles from the stow directory.
stormbrew 11y ago
I do a variation on this where I have an alias in bash for `dit` that makes it `git --git-dir=~/.config/dit --work-tree=~` and use that to manage my dot files. Avoids a bunch of the common issues with using git directly.
ashitlerferad 10y ago
Or take a look at vcsh and the other projects here: http://vcs-home.branchable.com/ http://vcs-home.branchable.com/
voltagex_ 10y ago
I've got my configs stored in a git repo at ~/configs, which contains a makefile that sets up symlinks for me.

jiiam 11y ago

This seems like an astonishingly good idea. It maybe lacks features for my home computer, but would be good for throw away servers like those you get from DigitalOcean, where I systematically set up everything over and over again each time.

corndoge 11y ago

I fail to see how this comes with the convenience of directory-specific symbolic links, dotfile-specific backups, individual removal & replacement of dotfiles, etc etc. I've been using stow for years to manage my dotfiles and it's never been more involved than $ stow dotfiles/urxvt or what have you. In fact I would say that managing a git repository is more of a waste of time and far more over-engineered for a task easily solved by a tiny binary. Not sure what you're referring to by an 'install script', have you ever used stow? In any case, the real answer is that you should be using whatever works best for your use case, and for me that's stow.

pmoriarty 11y ago
That does not work for me. When I try "stow foo/bar" I get this error: Undefined subroutine &main::error called at /usr/bin/stow line 568, <DATA> line 18. where line 568 of /usr/bin/stow is: error("Slashes are not permitted in package names"); What version of stow do you have? I'm using stow 2.2.0-r2 on Gentoo Linux.
- dbbolton 11y ago
  From the documentation page: >A package directory is the root of a tree containing the installation image for a particular package. Each package directory must reside in a stow directory — e.g., the package directory /usr/local/stow/perl must reside in the stow directory /usr/local/stow. The name of a package is the name of its directory within the stow directory — e.g., perl. https://www.gnu.org/software/stow/manual/stow.html https://www.gnu.org/software/stow/manual/stow.html The article in the OP also doesn't use this format. Instead it's prefaced with a `cd` command, so you would need to do: cd foo; stow bar
- corndoge 10y ago
  I use xstow, which permits slashes; usually I do just cd into the dotfiles directory and stow out from there (otherwise you need to specify a target directory) but I left that part out for brevity.

tomphoolery 11y ago

I made a script which makes that kind of thing easier to manage: https://github.com/tubbo/homer https://github.com/tubbo/homer

Pirate-of-SV 11y ago

That's a really nice solution actually, letting git do the magic. I'm definitely gonna try it. At the moment I use a python install script that backup already existing files and set up the symlinks.

saulrh 11y ago

I did this for a while. I had to switch to stow when I got a new job that had data security requirements - I had to keep the "work" bits of my dotfiles separate from the non-work parts, and so couldn't keep everything in the same git repository. Ended up writing a set of rcs that just imported appropriate .d directories, keeping two git repos, and stowing both of them.

sciencerobot 11y ago

I tried this but git uses ~/.git for any subdirectory of $HOME. For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository. It's easy to undo but still kind of annoying.

nebulous1 11y ago
You can add export GIT_CEILING_DIRECTORIES=~ to your .bashrc (or equivalent)
justinmk 11y ago
> For example, if you type `git add .` while in ~/code/some-project, you will add it to your dotfiles repository. If your project has its own .git directory, no, it won't add to ~/.git.
- sciencerobot 10y ago
  You're right. I forgot to mention that this only happens if you haven't initiated a new git repository in the directory you're working in.

noctuid 11y ago

I agree. I looked at quite a few dotfile managers, and all of them were overly complicated and couldn't replace my use of stow. Stow was not created as a "dotfiles manager" though, and keeping dotfiles seperate from all the other crud under ~/ is a lot cleaner in my opinion. I don't want my home directory to be a git repo either.

avar 11y ago

I do pretty much this but I have public dotfiles (on github), then an overlay for work files so I need a script to maintain those symlinks, and then work ones that I don't share with coworkers (contain private passwords). So I have a script that manages the symlinks for multiple such repos, knows to remove the broken links as needed, and I have something I can just paste into the terminal of any machine and it'll set that box up with my public/work/private dotfiles as appropriate. It's not perfect, but it works, just pointing out that even for relatively simple cases having a dotfile manager (or writing your own) can make sense.

weinzierl 11y ago
I still resolve the "overlay for work files" situation manually. Would you care to share your script?
- avar 10y ago
  Okey, but prepere for some super-lame ad-hoc code. Also I was misremembering about it handling multiple repos, in the one place where I have >1 I just do that manually. My .bashrc will run a bootstrap_work_dotfiles function when bash starts: https://github.com/avar/dotfiles/blob/master/.bashrc#L410 https://github.com/avar/dotfiles/blob/master/.bashrc#L410 This then clones my ~/g/avar-dotfiles-work repo if I'm at work and it hasn't been cloned: https://github.com/avar/dotfiles/blob/master/.bashrc#L355 https://github.com/avar/dotfiles/blob/master/.bashrc#L355 I have a "dud" function (dotfile update) function that'll update both, it basically does a git pull, re-chmods ~/.ssh/config: https://github.com/avar/dotfiles/blob/master/.bashrc#L381 https://github.com/avar/dotfiles/blob/master/.bashrc#L381 And also, and what you asked for, removes any stale symlinks via this one-liner: https://github.com/avar/dotfiles/blob/master/.bashrc#L348 https://github.com/avar/dotfiles/blob/master/.bashrc#L348 Basically doing a find on my ~ directory and finding any broken links pointing to the known location of the overlay repo. I see now that there's a potential bug in it where it narrows its search in such a way that it could miss it if you add/remove new ~/.??* files. This could be solved, but I have it like that because I only ever add/remove stuff in e.g. ~/.bashrc.d/ or ~/.screenrc.d/, so this way the find takes less time to run. Then I have a generated one-liner that I can paste into new machines that clones my dotfiles.git into ~/g/, moves the .git to ~/, then sources bashrc which bootstraps the rest.

hk__2 11y ago

I don’t want to have a Git repository in my $HOME; I prefer to have it somewhere else correctly organized then symlink everything.

tgamblin 11y ago
I manage my dotfiles in a separate git repo in ~/.dotfiles, and I have simple scripts that link and unlink everything. It's worked well for me for quite some time: https://github.com/tgamblin/dotfiles https://github.com/tgamblin/dotfiles

lolidaisuki 11y ago

With stow you can have just one git repo for all of your dotfiles instead of one per host if there are differences. Then you can just install the host specific dotfiles from the stow directory.

stormbrew 11y ago

I do a variation on this where I have an alias in bash for `dit` that makes it `git --git-dir=~/.config/dit --work-tree=~` and use that to manage my dot files. Avoids a bunch of the common issues with using git directly.

ashitlerferad 10y ago

Or take a look at vcsh and the other projects here: http://vcs-home.branchable.com/ http://vcs-home.branchable.com/

voltagex_ 10y ago

I've got my configs stored in a git repo at ~/configs, which contains a makefile that sets up symlinks for me.