On 2018-04-25 09:25 PM, Junio C Hamano wrote:
Marc Branchaud <marcn...@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.
