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

> 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?

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