Reset sometimes updates mtime

I'm seeing some behaviour with git reset that I find odd. Basically if I do

git fetch && \ git reset --hard simple-tag-that-points-to-the-current-commit

sometimes the reset will update the mtime of all files and directories in the repo and sometimes it will leave them alone. Changing it to

git fetch && \ git status && \ git reset --hard simple-tag-that-points-to-the-current-commit

Cause the mtime update to reliably not happen.

Bad thing is that I am relying on the mtime updates not to happen if the files don't actually change. Is this an assumption I can safely make? If it is, then I'll debug further (e.g. I don't even know yet if the file gets rewritten or just touched, why the index gets updated as well etc.).

Dennis Kaarsemaker <dennis@kaarsemaker.net> writes:

If my theory on what is happening is correct, I do not think there is any bug in what "reset --hard" is doing.

My theory is that something is causing the stat info that is cached in your index and the lstat(2) return you get from your working tree files go out of sync. Even though you are not actively touching any working tree files (otherwise, you wouldn't be complaining about mtime changing in the first place), perhaps your build of Git records timestamps in NS but your filesystem and the operating system does not preserve nanosecond resolution of timestamps when it evicts inode data from the core, or something like that? If that is what is happening, I think that "fetch" is a red herring, but any operation that takes some time and/or hits filesystem reasonably hard would trigger it.

And the reason why I say there is no bug in what "reset --hard" is doing here, if the above theory is correct, is because:

 - The user asked "reset --hard" to "make sure that my working tree
   files are identical to those of HEAD";

 - "reset --hard" looks at lstat(2) return and the cached stat info
   in the index and find them not to match.  It can do one of two
   things:

   (1) see if the user did something stupid, like "touch file", that
       modifies only lstat(2) info without actually changing its
       contents, by reading from the working tree, reading HEAD:file
       from the object database, and comparing them, and overwrite
       the working tree file only when they do not match.

       or

   (2) the contents might happen to be the same, but the end result
       user desires to have is that the contents of the working tree
       file is the same as that from the HEAD, so overwrite it
       without wasting time reading two and compare before doing so.

   and it is perfectly reasonable to do the latter.  After all, the
   whole point of having its cached lstat(2) data in the index is to
   so that we do not have to always compare the contents before
   deciding something has changed in the working tree.

Running "git update-index --refresh" immediately before "reset" may alleviate the issue. "git status" has the same effect, only because it does "update-index --refresh" at the beginning of its processing, but it wastes a lot more time and resource doing other things.

But unless/until you know _why_ the cached stat info in your index goes stale relative to what lstat(2) tells you, it would not "solve" it, because that magical thing (and my theory is cached data in your operating system that keeps a file timestamp with more precision than your underlying filesystem can represent is being flushed, and reading the file timestamp back from the disk has to truncate the nanoseconds part) can happen at any time between the "--refresh" and your "reset".

On do, 2015-07-09 at 10:56 -0700, Junio C Hamano wrote:

Thanks Junio!

If I understand you correctly, reset should not touch files if it thinks they are up-to-date, so at least that assumption is safe to make. I'll test your theory about why reset thinks all the files are outdated.

I did notice 'fetch' updates the index (well, mtime of .git/index
changes, I didn't look at index content yet), so maybe fetch isn't quite
a red herring. I'll try to eliminate this variable as well.