From: Marc Branchaud Date: Thu, 26 Apr 2018 14:12:11 GMT Subject: Re: [RFC PATCH] checkout: Force matching mtime between files Message-ID: <8a7e0d0c-a821-b289-b390-ca9818f6770b@xiplink.com> In-Reply-To: On 2018-04-25 09:25 PM, Junio C Hamano wrote: > Marc Branchaud 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.