On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote: > In order to avoid unnecessary cache mismatches, force a matching mtime > between all files created by a single checkout action. This seems to be > the best course of action. Matching mtimes do not trigger cache > updates. They also match the concept of 'checkout' being an atomic > action. Finally, this change does not break backwards compatibility > as the new result is a subset of the possible previous results. There's one case that might be regressed. As long as we assume time always moves forward, I think you're right, but... > diff --git a/unpack-trees.c b/unpack-trees.c > index e73745051..e1efefb68 100644 > --- a/unpack-trees.c > +++ b/unpack-trees.c > @@ -346,6 +346,7 @@ static int check_updates(struct unpack_trees_options *o) > state.quiet = 1; > state.refresh_cache = 1; > state.istate = index; > + state.checkout_mtime = time(NULL); ISTR that it's possible for "system time" to be different from "filesystem time". Is there any case where the time we get from time(NULL) might vary wildly from what would be written by the filesystem if we were to simply write the file? E.g., perhaps on some types of network-mounted filesystems. The files in your checkout would all be consistent, but they might be inconsistent with other files _not_ created by Git (e.g., one might be saved in your editor). Now you may have introduced skew that cause "make" to do the wrong thing, because your source and target files are really operating from two different clocks. I really don't know how possible or common this is, but I feel like I've been warned about this distinction in the past. I wouldn't be surprised to find that it's an archaic thing found only on ancient versions of NFS, and oral tradition passed down the warnings. But I also would not be surprised if it's still possible and common. -Peff
