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

From: Junio C Hamano <gitster@pobox.com>
To: "Robin H. Johnson" <robbat2@gentoo.org>
Cc: "Git Mailing List" <git@vger.kernel.org>,
	"Michał Górny" <mgorny@gentoo.org>, "Jeff King" <peff@peff.net>,
	"Lars Schneider" <larsxschneider@gmail.com>,
	"Marc Branchaud" <marcnarc@xiplink.com>
Subject: Re: [RFC PATCH] checkout: Force matching mtime between files
Date: Wed, 25 Apr 2018 17:48:37 +0900	[thread overview]
Message-ID: <xmqqin8f4qoq.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <robbat2-20180425T060717-325652820Z@orbis-terrarum.net> (Robin H. Johnson's message of "Wed, 25 Apr 2018 07:13:38 +0000")

"Robin H. Johnson" <robbat2@gentoo.org> writes:

> In the thread from 6 years ago, you asked about tar's behavior for
> mtimes. 'tar xf' restores mtimes from the tar archive, so relative
> ordering after restore would be the same, and would only rebuild if the
> original source happened to be dirty.
>
> This behavior is already non-deterministic in Git, and would be improved
> by the patch.

But Git is not an archiver (tar), but is a source code control
system, so I do not think we should spend any extra cycles to
"improve" its behaviour wrt the relative ordering, at least for the
default case.  Only those who rely on having build artifact *and*
source should pay the runtime (and preferrably also the
maintainance) cost.

The best approach to do so is to have those people do the "touch"
thing in their own post-checkout hook.  People who use Git as the
source control system won't have to pay runtime cost of doing the
touch thing, and we do not have to maintain such a hook script.
Only those who use the "feature" would.