Jeff King <peff@xxxxxxxx> writes: > 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. It was pretty common back when I still was on NFS ;-) I do not think we care too deeply about a working tree that spans across filesystem boundary, so one possible workaround is to read the fs timestamp back out of the _first_ file we write in the process, and then consistently use that time for the rest of the files that are checked out by the same process with utimes(). I personally still do not think it is worth the complication; these projects are "holding it wrong" by placing build artifacts in SCM (not in tarball) ;-).
