Sure, I do exactly this from time to time using
git update-index --assume-unchanged [<file> ...]
To undo and start tracking again (if you forgot what files were untracked, see this question):
git update-index --no-assume-unchanged [<file> ...]
Relevant documentation:
--[no-]assume-unchanged
When this flag is specified, the object names recorded for the paths are not updated. Instead, this option sets/unsets the "assume unchanged" bit for the paths. When the "assume unchanged" bit is on, the user promises not to change the file and allows Git to assume that the working tree file matches what is recorded in the index. If you want to change the working tree file, you need to unset the bit to tell Git. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2)
system call (e.g. cifs).
Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.
Fail gracefully in this case means, if there are any changes upstream to that file (legitimate changes, etc.) when you do a pull, it will say:
$ git pull
…
From https://github.com/x/y
72a914a..106a261 master -> origin/master
Updating 72a914a..106a261
error: Your local changes to the following files would be overwritten by merge:
filename.ext
and will refuse to merge.
At that point, you can overcome this by either reverting your local changes, here’s one way:
$ git checkout filename.ext
then pull again and re-modify your local file, or could set –no-assume-unchanged
and you can do normal stash and merge, etc. at that point.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…