Re: Files modified, even after: git reset --hard
- From
Chris Torek <chris.torek@gmail.com>
- Date
- Jul 26, 2021, 22:03 UTC
- Message-ID
- <CAPx1Gvey1uSr58Uf7VpC0c6J+R0tUP=VUP_dGmv_yVO-CwmvXg@mail.gmail.com>
- In-Reply-To
- <67f35be7-3317-6486-cdb6-62eb691eaf10@mfriebe.de>
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