Rather than just having per-machine branches, what I do is have per-tool branches - base/zsh, base/vim, base/git etc. Then I merge these onto branches named, e.g mix/home, mix/work/common and then onto more specific branches - mix/work/solaris etc. There is a single empty commit as a parent of all the branches so octopus merges mostly work. This allows me to track machine specific changes but have my core configuration for, e.g. zsh clear of the specifics of particular sites. I’ve also managed to push shallow clones where I’ve not wanted full history.
The mental overhead of this would kill me, this sounds more complicated than most of the work projects I have with a full team of people doing feature branches :P
That said, maybe I’m just using it different enough that rare updates + a few lines of overwritten config per host solve all of these problems for me.
That’s it. No idea why people insist on symlinks, install scripts, “gnu stow” and various other over-engineered things. Well, actually I have an idea of why people insist on over-engineered things ;)
I did that for a while, but I find it really easy to accidentally mess stuff up badly by thinking you’re in a directory with a git repo but then you’re accidentally running against your ~/.git. That’s not an issue if everything is pushed to a server (unless what you accidentally ran included git push -f), but if there”s been a while since you pushed (or, god forbid, a while since you committed), it’s possible to lose quite a bit of work that way.
Maybe one solution would be to use something like ~/.dotfiles-git instead of ~/.git and alias dotgit to git --git-dir=~/.dotfiles-git --work-tree=~ ? We’d have the same simplicity benefits, but just running regular git commands in the wrong dir wouldn’t have any effect (and IDEs and text editors which try to scan the git dir to be useful wouldn’t be as sad).
I do pretty much the same, but with Mercurial. No need to run setup to shuffle symlinks, or have the repo outside ~ itself when I’m making changes, and where one might git clone to pull in other projects in a setup script, I do have a script can add them, but my config degrades gracefully without them. I can pull stuff in if I want to, and function fine without. I don’t think I’ve run into any trouble or surprises doing this, so I’m not sure what the advantages of other schemes might be.
Are you joking? That’s an example of the very thing I want to avoid. The “manual” steps I describe above are not more complicated than the steps needed to install and use a “shell plugin” or other third-party tool.
no, not joking…just trying to help. i did the above for years and got annoyed trying to remember the right commands to run. Homer does a few more things than just the home directory repo thing but that’s one of its big features.
That makes sense if dotfiles is the only thing you use git for, or you’re in a situation where the only git commands you really need are git clone/add/commit/push. However, as I’ve gotten used to how git actually works through years of contributing to open source and working professionally with other people, what /u/jmk is suggesting doesn’t look like commands I would have to remember any more than how you have to remember that cd <directory> goes to a directory or tar czf foo.tgz foo makes a compressed tarball of foo.
I’ve used yadm, which implements exactly this. I’ve used it for a year and it Just Works. I think I heard about it from this thread. Coincidentally for this link, I use Atlassian’s BitBucket service to host my dotfiles repo, because to avoid sharing personal or work credentials from GitHub with the other environment.
The –git-dir, yes, to avoid always treating home as git. Bare repo is not strictly necessary, but without it you’d have an extra copy of dotfiles next to .git directory which might be confusing.
It’s a “home directory manager”, taking a cue from tools like Homebrew and GNU Stow, but slightly different from both of them. All it really does is set your home directory up as a Git repository, adds some special .gitignore magic to ensure that you don’t accidentally commit everything to the repo, and provides some useful commands for managing this repo anywhere on the machine.
Rather than just having per-machine branches, what I do is have per-tool branches - base/zsh, base/vim, base/git etc. Then I merge these onto branches named, e.g mix/home, mix/work/common and then onto more specific branches - mix/work/solaris etc. There is a single empty commit as a parent of all the branches so octopus merges mostly work. This allows me to track machine specific changes but have my core configuration for, e.g. zsh clear of the specifics of particular sites. I’ve also managed to push shallow clones where I’ve not wanted full history.
The mental overhead of this would kill me, this sounds more complicated than most of the work projects I have with a full team of people doing feature branches :P
That said, maybe I’m just using it different enough that rare updates + a few lines of overwritten config per host solve all of these problems for me.
This is nice. But it’s still more setup than needed. Instead I just
.gitignoreeverything and force-add the things I want to add.Starting from zero:
To add a file, use the “force” option:
To setup a new computer:
That’s it. No idea why people insist on symlinks, install scripts, “gnu stow” and various other over-engineered things. Well, actually I have an idea of why people insist on over-engineered things ;)
I did that for a while, but I find it really easy to accidentally mess stuff up badly by thinking you’re in a directory with a git repo but then you’re accidentally running against your ~/.git. That’s not an issue if everything is pushed to a server (unless what you accidentally ran included
git push -f), but if there”s been a while since you pushed (or, god forbid, a while since you committed), it’s possible to lose quite a bit of work that way.Maybe one solution would be to use something like
~/.dotfiles-gitinstead of~/.gitand alias dotgit togit --git-dir=~/.dotfiles-git --work-tree=~? We’d have the same simplicity benefits, but just running regular git commands in the wrong dir wouldn’t have any effect (and IDEs and text editors which try to scan the git dir to be useful wouldn’t be as sad).I do pretty much the same, but with Mercurial. No need to run setup to shuffle symlinks, or have the repo outside
~itself when I’m making changes, and where one mightgit cloneto pull in other projects in a setup script, I do have a script can add them, but my config degrades gracefully without them. I can pull stuff in if I want to, and function fine without. I don’t think I’ve run into any trouble or surprises doing this, so I’m not sure what the advantages of other schemes might be.if you do this manually right now, check out https://github.com/tubbo/homer :)
Are you joking? That’s an example of the very thing I want to avoid. The “manual” steps I describe above are not more complicated than the steps needed to install and use a “shell plugin” or other third-party tool.
no, not joking…just trying to help. i did the above for years and got annoyed trying to remember the right commands to run. Homer does a few more things than just the home directory repo thing but that’s one of its big features.
That makes sense if dotfiles is the only thing you use git for, or you’re in a situation where the only git commands you really need are git clone/add/commit/push. However, as I’ve gotten used to how git actually works through years of contributing to open source and working professionally with other people, what /u/jmk is suggesting doesn’t look like commands I would have to remember any more than how you have to remember that
cd <directory>goes to a directory ortar czf foo.tgz foomakes a compressed tarball of foo.Recent related thread
Consider this: Track your ~/.config via git, and for programs that don’t support that directory, you create symlinks. Advantages:
I’ve been using this for the last several months. Switched over from a homeshick setup. I’m liking it now.
My repo with a README showing my simple workflow: https://github.com/kelp/dotfiles
I’ve used yadm, which implements exactly this. I’ve used it for a year and it Just Works. I think I heard about it from this thread. Coincidentally for this link, I use Atlassian’s BitBucket service to host my dotfiles repo, because to avoid sharing personal or work credentials from GitHub with the other environment.
So the reason they use the bare repo and set up the alias, etc. is so that git and other tools don’t treat your entire home directory as a repository?
The –git-dir, yes, to avoid always treating home as git. Bare repo is not strictly necessary, but without it you’d have an extra copy of dotfiles next to .git directory which might be confusing.
I have a very similar plugin for the shell that I’ve been using for a few years now, called Homer.
https://github.com/tubbo/homer
It’s a “home directory manager”, taking a cue from tools like Homebrew and GNU Stow, but slightly different from both of them. All it really does is set your home directory up as a Git repository, adds some special
.gitignoremagic to ensure that you don’t accidentally commit everything to the repo, and provides some useful commands for managing this repo anywhere on the machine.