-1

I have some files with "settings" (say, Eclipse *.prefs files) that I don't want to track. They were already being tracked (because I didn't set something up right), but it looked like git rm --cached was how to stop the files from being tracked. I tried this, and now git status lists the files as deleted:, but they're still there in my directory. So far, so good.

Suppose that I use git commit in the current state; it will create a new commit C1 but won't track those files. Suppose that some time later, and after several more commits, and assuming I've made some changes to my settings files, I use git checkout to revert to the commit C1. Will this remove the no-longer-tracked settings files, or just leave them alone? I'm concerned about how Git knows the difference, when checking out an earlier commit, between "this file isn't in the commit so I'm going to remove it", and "this file should be left alone". The fact that Git is reporting the files as deleted: makes me a bit more concerned, I guess, although perhaps that's just inaccurate output.

ajb
  • 31,309
  • 3
  • 58
  • 84

1 Answers1

2

Git does a check before doing a checkout to see if there are any files in the directory that aren't tracked, but which exist in the commit that's about to be checked out. If there are any it tells you it can't do the checkout, because files would be overwritten. You can move/rename them and try again, or try again using the --force option, which will forcibly overwrite whatever needs to be overwritten.

Gary Fixler
  • 5,632
  • 2
  • 23
  • 39
  • Under what circumstances would `git checkout` delete a file in the directory? Ever? – ajb Oct 12 '13 at 03:21
  • I don't believe it ever does without forcing it. Git is pretty smart about not losing data. You can still do it, but git tries hard not to let it happen easily, as evidenced here: http://stackoverflow.com/questions/1125968/force-git-to-overwrite-local-files-on-pull – Gary Fixler Oct 12 '13 at 03:49