2

I just put my dotfiles in a repository in the manner suggested by Eli Barzilay here:

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.

My .git/info/exclude looks like this:

*
.*.swp
*~
\#*#
.DS_Store

The * on the first line successfully ignores all files, so I add things explicitly with git add -f. However, this has the side effect that files I want ignored slip through.

Is there a way to tell git to really ignore certain files, even though I use add -f?

shytikov
  • 9,155
  • 8
  • 56
  • 103
echristopherson
  • 6,974
  • 2
  • 21
  • 31
  • I would not use "add -f", but rather state the ignore correctly. So which file-types do you want to actually ignore here? – centic Aug 22 '12 at 20:44
  • @centic Basically almost all files should be ignored. I think, since I'm using this for dotfiles, I'll just ignore everything not starting with a period. In `git status` then I will see some dotfiles that I really don't care about, but since there shouldn't be that many I can just ignore them myself rather than making Git do it. That is, unless there's some sort of pre-commit or post-add hook I can use to "un-add" the files I really want to ignore. – echristopherson Aug 22 '12 at 22:28
  • then i dont think you can ignore more when using -f. – centic Aug 23 '12 at 05:25

1 Answers1

0

Right now there is no easy way to do this, because by putting * in .git/info/exclude you are essentially "blinding" git to which files you really want to be always ignored. That is one big downside of the detached working tree approach to dotfile management using git, and it's one of the reasons why I personally rejected this approach. Instead I wrote a plugin to mr which automates symlink farm management via GNU Stow.

However if you still want to stick with the detached working tree approach, you should definitely look at vcsh rather than reinventing wheels. I am currently working on making git's ignore mechanism more scriptable, and it's possible that this work could be consumed by tools like vcsh in the future to at least partially solve this problem. (I know vcsh's author and have just suggested this idea to him on IRC.)

Finally, I'd recommend hanging out with the vcs-home guys to understand all the options better.

Community
  • 1
  • 1
Adam Spiers
  • 17,397
  • 5
  • 46
  • 65