On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud [off-list ref] wrote:

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 have a feeling this has "this is linux" assumption. Anybody knows
how freebsd, mac os x and windows behave?

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.

Would a hook that gives you the list of updated files (in the exact
same order that git updates) help?

* 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.)

This to me sounds like something we should be able to improve in
general. The alternative is "git clone --no-checkout" then checkout
manually (which I see jenkins plugin does) is really not optimal even
if it works.
-- 
Duy