Interesting post from one of the top contributors in Git on Stack Overflow: +Amber Yust. (  

I like the idea of having your dotfiles versioned in a subdirectory of your homedir.
That could mean symlinking your dotfiles to that subdir, but in this SO question (, you have a reference to ( Eli Barzilay's comment (, which I find interesting:

- either make your home a git repository,
- or use symlinks to the actual repository.

Eli adds:

I dislike the first for the usual reasons: more than the problem of seeing your whole world as untracked files without setting a default, there’s a more serious problem of your home directory being an actual git repo. What if you run some git command expecting it to do something except you’re not in the right directory? Usually, this will be an error (unless you’re in a different repo), but now this is guaranteed to be a mess.

OTOH, I dislike the symlink approach for more than just the minor hassle of a one-line script that creates the symlinks… What if some program updates a file by replacing the existing one?  
In that situation not only will it break the link to the repo and you won’t see the change, but as an added bonus the usual careless one-liner that creates symlinks will overwrite the replaced file with the previous contents therefore evaporating the new contents.  
Another problem: what if you want things to work reasonably well on cygwin, where symlinks are not really visible as such to native windows programs?

So I’ve finally found a solution that takes the best of both:  
put the repo in a subdirectory, and instead of symlinks, add a configuration option for “core.worktree” to be your home directory.  
Now when you’re in your home directory you’re not in a git repo (so the first problem is gone), and you don’t need to deal with fragile symlinks as in the second case.  
You still have the minor hassle of excluding paths that you don’t want versioned (eg, the “*” in “.git/info/exclude” trick), but that’s not new.
Shared publiclyView activity