On 2018-04-25 04:48 AM, Junio C Hamano wrote:
"Robin H. Johnson" <robbat2@xxxxxxxxxx> writes:
In the thread from 6 years ago, you asked about tar's behavior for
mtimes. 'tar xf' restores mtimes from the tar archive, so relative
ordering after restore would be the same, and would only rebuild if the
original source happened to be dirty.
This behavior is already non-deterministic in Git, and would be improved
by the patch.
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.
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.
The best approach to do so is to have those people do the "touch"
thing in their own post-checkout hook. People who use Git as the
source control system won't have to pay runtime cost of doing the
touch thing, and we do not have to maintain such a hook script.
Only those who use the "feature" would.
The post-checkout hook approach is not exactly straightforward.
Naively, it's simply
for F in `git diff --name-only $1 $2`; do touch "$F"; done
But consider:
* Symlinks can cause the wrong file to be touched. (Granted, Michał's
proposed patch also doesn't deal with symlinks.) Let's assume that a
hook can be crafted will all possible sophistication. There are still
some fundamental problems:
* In a "file checkout" ("git checkout -- path/to/file"), $1 and $2 are
identical so the above loop does nothing. Offhand I'm not even sure how
a hook might get the right files in this case.
* The hook has to be set up in every repo and submodule (at least until
something like Ævar's experiments come to fruition).
* A fresh clone can't run the hook. This is especially important when
dealing with submodules. (In one case where we were bit by this, make
though that half of a fresh submodule clone's files were stale, and
decided to re-autoconf the entire thing.)
I just don't think the hook approach can completely solve the problem.
I appreciate Ævar's concern that there are more than just two mtime
requests floating around. But I think git's users are best served by a
built-in approach, with a config setting to control the desired mtime
handling (defaulting to the current behaviour). People who want a
different mtime solution will at least have a clear place in the code to
propose a patch.
M.
