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

[Chris Torek <chris.torek@gmail.com>]

On Mon, Jul 26, 2021 at 12:57 PM Martin <git@mfriebe.de> 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