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

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Apr 23 2018, Junio C. Hamano wrote:

> "Robin H. Johnson" <robbat2@gentoo.org> writes:
>
>> On Fri, Apr 13, 2018 at 07:01:29PM +0200, Michał Górny wrote:
>>> Currently git does not control mtimes of files being checked out.  This
>>> means that the only assumption you could make is that all files created
>>> or modified within a single checkout action will have mtime between
>>> start time and end time of this checkout.  The relations between mtimes
>>> of different files depend on the order in which they are checked out,
>>> filesystem speed and timestamp precision.
>>> ...
>> Junio: ping for review or inclusion of this patch?
>
> I personally did not think this is a good idea and not worth any
> code contamination with calls to utime().  Is there anybody sane who
> thought this was a good idea in the discussion thread?

I think given that this keeps coming up it would be nice if Git had some
easy facility to do this type of thing, because it's clearly a common
use-case, but I don't think this is the route that should be taken.

By doing it this way we're imposing a fixed cost on checkouts for people
who don't care about this, and this will be mutually exclusive with
other potential approaches.

I think a sane path towards something like this is closer to:

 1. Add ability to have multiple hooks, similar to what I had as a WIP
    in
    https://public-inbox.org/git/CACBZZX6j6q2DUN_Z-Pnent1u714dVNPFBrL_PiEQyLmCzLUVxg@mail.gmail.com/
    and what
    e.g. https://docs.gitlab.com/ee/administration/custom_hooks.html
    implements (partially) in the wild.

 2. Add some config so we can have hook search paths, and ship with a
    default search path for hooks shipped with git.

 3. Then users can trivially enable e.g the
    post-checkout-consistent-mtimes hook, which could either ship with
    git itself, or be its own project.

As it is we've had several threads recently where people have wanted
different mtime solutions, e.g. consistent mtimes within one checkout,
or the mtime of when the file was last changed according to git etc.

I don't think it's a sane approach that the git checkout code learn to
do all of that natively, but I *do* think it's sane that we improve hook
support so we can run whatever custom logic people want at the right
time, which could run around re-setting mtimes.