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

From: Marc Branchaud <marcnarc@xiplink.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Robin H. Johnson" <robbat2@gentoo.org>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Michał Górny" <mgorny@gentoo.org>, "Jeff King" <peff@peff.net>,
	"Lars Schneider" <larsxschneider@gmail.com>,
	"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [RFC PATCH] checkout: Force matching mtime between files
Date: Thu, 26 Apr 2018 10:12:11 -0400	[thread overview]
Message-ID: <8a7e0d0c-a821-b289-b390-ca9818f6770b@xiplink.com> (raw)
In-Reply-To: <xmqqefj24v3c.fsf@gitster-ct.c.googlers.com>

On 2018-04-25 09:25 PM, Junio C Hamano wrote:
> Marc Branchaud <marcnarc@xiplink.com> writes:
> 
>>> 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.
>>
>> Anyone who uses "make" or some other mtime-based tool is affected by
>> this.  I agree that it's not "Everyone" but it sure is a lot of
>> people.
> 
> That's an exaggerated misrepresentation.  Only those who put build
> artifacts as well as source to SCM *AND* depend on mtime are
> affected.
> 
> A shipped tarball often contain configure.in as well as generated
> configure, so that consumers can just say ./configure without having
> the whole autoconf toolchain to regenerate it (I also heard horror
> stories that this is done to control the exact version of autoconf
> to avoid compatibility issues), but do people arrange configure to
> be regenerated from configure.in in their Makefile of such a project
> automatically when building the default target?

Yes.  I've seen many automake-generated Makefiles with "recheck" 
machinery that'll conveniently rerun autoconf if "necessary".

(And those horror stories are true, BTW.)

> In any case, that is
> a tarball usecase, not a SCM one.

No, it's an SCM case when you need to have the project's code as part of 
your own.  I can't make everyone do things the Right Way, so I'm stuck 
using projects that are not 100% pure-source, because they "helpfully" 
release their code after the autoconf step for some reason.

>> Are we all that sure that the performance hit is that drastic?  After
>> all, we've just done write_entry().  Calling utime() at that point
>> should just hit the filesystem cache.
> 
> I do not know about others, but I personally am more disburbed by
> the conceptual ugliness that comes from having to have such a piece
> of code in the codebase.

The ugliness arises from the problem being solved.  It's not git's fault 
that the world is so stupid.

That git might be willing to suffer a bit of self-mutilation for the 
benefit of its users should be seen as a point of pride.

		M.