Hi Stephen, On Wed, 12 Apr 2017, Stephen Hicks wrote: > On Wed, Apr 12, 2017 at 3:05 PM, Johannes Schindelin > <Johannes.Schindelin@xxxxxx> wrote: > > > > On Tue, 11 Apr 2017, Stephen Hicks wrote: > > > > > I'm hesitant to only use mtime, size, and inode, since it's quite > > > likely that these are all identical even if the file has changed. > > > > Not at all. The mtime and the size will most likely be different. > > In my experience, mtime is almost always the same, since the file is > written pretty much immediately before the exec - as long as the > command takes a small fraction of a second (which it usually does) the > mtime (which is in seconds, not millis or micros) will look the same. Oh, I see, you assume that mtime is in seconds. However, on pretty much all platforms supported by Git we use nanosecond-precision mtimes [*1*]. In practice, the mtimes are not always nanosecond-precision, as some file systems have a coarser granularity. It is typically a pretty fine a granularity, though, much finer than a second [*2*]. My mistake, I should have explained that I wanted to suggest adding a field of type `struct cache_time` to the `todo_list` structure, and to use ST_MTIME_NSEC(&st) to populate and compare the `nsec` part of that. Ciao, Johannes Footnote *1*: The platforms for which we disable nanosecond mtimes are: OSF-1, AIX, HP-UX, Interix, Minix, NONSTOP_KERNEL (?), and QNX. (If you look at git.git's config.mak.uname, you will see that Git for Windows' nanosecond support has not yet made it upstream.) In other words, the major platforms (Windows, MacOSX and Linux) all compare the nanosecond part of the mtime. Footnote *2*: the coarsest mtime of which I know is FAT32 (2-second granularity). If you want to use Git on such a file system, well, that's what you get. And then some performance penalties, too. It would appear from a quick web search that ext4 has true nanosecond granularitry. NTFS has a 100ns granularity which is still plenty enough for our purposes.