Is it bad practice to git init in the $home directory to keep track of dot files?

I want to backup and sync my dotfiles using github. Since all the dotfiles resides in $home by default, should I just git init in my $home folder, or is that a bad idea?

Having performed git init in $home, my idea is then to .gitignore all non-dotfiles and non-dotfolders.

4

8 Answers

Create a "bare" git repository:

cd $HOME
git init --bare .dotfiles

The --bare flag creates a repository that doesn’t have a working directory, making it impossible to edit files and commit changes in that repository.

Create an alias to manage the repository we just created:

alias dotfiles="/usr/bin/git --git-dir=$HOME/.dotfiles/ --work-tree=$HOME"

Ignore the files that are not being tracked from being shown up in git status:

dotfiles config --local status.showUntrackedFiles no

Add your desired files:

dotfiles add .bash_aliases

Commit.

dotfiles commit -m 'Add .bash_aliases'

---

Now with the use of a bare repository, there is no .git directory in your $HOME directory; so it does not introduce any surprises while working with git.

That's how I manage my dotfiles. I first read about it here years ago.

5

It is a good practice, but you should ignore all files by default and just add the files you need. Here is an example of a .gitignore:

# ignore all
*
# include dot files (including .gitignore)
!.*

You can also exclude other files putting other lines at the end of your .gitignore:

# ignore all
*
# include dot files (including .gitignore)
!.*
.ssh 

4

If you're slightly uneasy about having a git repository in your home folder (which I would be), you might consider this idea:

• Create a git repository somewhere else, e.g. ~/src/configuration or ~/etc or wherever you like.
• Put all your configuration files in there.
• Replace your configuration files (at the normal paths) with symlinks into this repository.
• Perhaps write a simple shell script which checks that the symlinks point where you expect them to, and run it e.g. daily in a cron job.

Every problem in computing can be solved with an additional layer of indirection ;-)

1

I'd say it is a bad practice, indeed. None of the tutorials at or will have you track the home folder directly into a home-level git repository. Most will manually copy or symlink the files.

While git tracking your dotfiles is a great idea, having a git repo at home level makes it easy to accidentally run commands to that repo when you actually mean to run it in a more specific directory repository.

For example:

mkdir ~/Projects/my-awesome-web-app
cd ~/Projects/my-awesome-web-app
npm init # initializes node projects, creates package.json
git add package.json # would not fail, since it's actually inside a git repo
git commit -m "starts work" # actually commits to the home repo, not locally

Also, Anish Athalye chooses not to track home folder directly under git:

• There is no possibility of accidentally deleting your files. With your entire home directory under version control, running something like a git clean could wipe out everything in your home directory that is not tracked by your VCS.
• It is possible to track configuration files that belong somewhere other than $HOME.
• Installing dotfiles on new machines is easier. All that is required is cloning your dotfiles followed by copying or linking files. Keeping the entire home directory under version complicates installation.

1

You could look at yadm, it does mainly this but I guess it is more secure and the setup may be easier. I think it is just a wrapper of git at first (it does have more features though), meaning that you can just use usual git commands replacing git by yadm (like yadm add/clone/status etc.)

I am not affiliated to yadm, just a happy user.

1

My solution for over 10 years has been a repository with public configuration and code. It includes a Makefile which does some basic checks and has an install target to create symbolic links in the home directory. This makes it harder to accidentally commit something which shouldn't be in there.

2

I do this, but have a whitelist of dotfiles, instead of including them all or having a blacklist. That is, my .gitignore ignores everything and then un-ignores only those files and directories I want to include.

Example "whitelisting" .gitignore:

*
!.vimrc
!.gitignore
!.otherdotfile

etc

There are many dotfiles it doesn't make much sense to keep versioned, like things that are cached files, things that are updated dynamically by graphical apps, and so on.

Also consider that your repository will contain private information in areas you don't expect, even if you exclude things like your SSH keys. Sharing this repository publicly is probably not a good idea.

Note also that if you have other git working trees in your home directory, you'll want the parent directories of those to be excluded from this repository so git doesn't start thinking they are sub-repositories or something.

Instead of using git, you may consider symlinking your dot files to a shared storage provider

• dropbox
• google drive
• keybase

There is a tool called mackup that will automatically create these symlinks and has support for a wide variety of other applications. Works on Linux and Mac

1

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password Submit

Post as a guest

Post Your Answer Discard

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy