How does git checkout know whether to remove a file or leave it alone? <p>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 <code>git rm --cached</code> was how to stop the files from being tracked. I tried this, and now <code>git status</code> lists the files as <code>deleted:</code>, but they're still there in my directory. So far, so good. </p> <p>Suppose that I use <code>git commit</code> 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 <code>git checkout</code> 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 <code>deleted:</code> makes me a bit more concerned, I guess, although perhaps that's just inaccurate output.</p>