+1 I've been using this for almost ten years. It's straightforward, easy to add files, and there are no symlinks to deal with.

When people ask me which tool I use to manage my dotfiles, I tell them about this little-known tool called `git`. ;)

Side note: I use an shell alias instead, but it's pretty much the same.

`alias home="git --work-tree=$HOME --git-dir=$HOME/.files.git"`

OP's first sentence refers to limitations of "version control $HOME" ... What are the limitations?

Ah, that is what OP was referring to.

Well, you can't have different configs for different hosts. Other than that, I can't quickly recall what other limitations are, I see none. I really like the simplicity of the "pure git" approach.

My dotfiles repo dates back to 2018, I'm happy user of this git one-liner for the past 6 years.

> you can't have different configs for different hosts

You can? Git is a DVCS, that's kinda the point of the Distributed part (although most people use it as a centralized VCS.

I have not only host specific configs, but also (host specific) work configs. It's really easy to merge/cherry pick changes between them.

> Well, you can't have different configs for different hosts

Though you can use git branches, but I prefer not to

Might be niche but for me - I have config files outside $HOME, I use a number of `.gitignore`-aware tools (tree, fuzzy finder), and I just don't like `git status` telling me I'm in a repo in any subdir of $HOME.

That's why I use --git-dir=$HOME/.dotfiles

I rename .git directory to .dotfiles in my $HOME