Marc Branchaud <marcnarc@xxxxxxxxxxx> 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? In any case, that is a tarball usecase, not a SCM one. > 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.
