Re: Files modified, even after: git reset --hard

On Mon, Jul 26, 2021 at 12:57 PM Martin [off-list ref] wrote:

Is it possible that those cheats also look at the "replaced" (rather
than the "replacement") commit(s)?

They look at `stat` system call (well, `lstat` *call*) data, not the
actual files.  This works better on Unix systems, where `lstat` is
a real system call, than it does on Windows, where it's faked up
from whatever Windows really stores as information about files.

I am pretty sure I have "git replace"d all blobs for some of the files,
and yet they do get phantoms.

The stat data are stored in Git's index.  It's the rebuilding of various
index entries that updates what Git uses to do a fast check of file
status.  (Note that the stat data on the index itself count as part of
the cheating; this gets tricky.  See [1].)

There is an article at [2] on how Windows implements `stat`. It's
probably out of date (says "VS2005").  It's interesting to me what's
wrong here: `st_dev` is made to mirror `st_rdev` but `st_dev` should
probably always just be zero, and they chose to attempt to store a
file *creation* time in `st_ctime`, when that is in `st_birthtime` in a
modern Unix-like system: the `ctime` field is the *inode change time*,
not a file creation time.  (Fortunately Git uses neither field.)

Chris

[1]: https://git-scm.com/docs/racy-git/en
[2]: https://web.archive.org/web/20101214222704/http://msdn.microsoft.com/en-us/library/14h5k7ff(v=vs.80).aspx