Re: [RFC PATCH] checkout: Force matching mtime between files

From: Junio C Hamano <gitster@pobox.com>
Date: May 6, 2018, 03:37 UTC
Message-ID: <xmqq8t8xsbcy.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180505184426.GA18385@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 11 quoted lines

> 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) ;-).