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

[Marc Branchaud <marcnarc@xiplink.com>]

On 2018-04-25 04:48 AM, Junio C Hamano wrote:
> "Robin H. Johnson" <robbat2@gentoo.org> 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.