On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud <[email protected]> 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
