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

From: Junio C Hamano <gitster@pobox.com>
Date: Apr 29, 2018, 23:56 UTC
Message-ID: <xmqqpo2hzhwg.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180426184411.GA6844@duynguyen.home>

Duy Nguyen <pclouds@gmail.com> writes:

Show 7 quoted lines

> Target revision should be available in the index. But this gives me an
> idea to another thing that bugs me: sending the list to the hook means
> I have to deal with separator (\n or NUL?) or escaping. This mentions
> of index makes me take a different direction. I could produce a small
> index that contains just what is modified, then you can retrieve
> whatever info you want with `git ls-files` or even `git show` after
> pointing $GIT_INDEX_FILE to it.

That's somewhere in between a tail wagging the dog and a hammer looking like a solution even when you have a screw. By passing a temporary index, you may be able to claim that you are feeding the necessary information without corruption and in a readable and native format of Git, and make it up to the reader to grab the paths out of it, but

 (1) the contents, and probably the cached stat information, in that
     temporary index is duplicated and wasted; you know from the
     time you design this thing that all you want to convey is a
     list of paths.

 (2) it is totally unclear who is responsible for cleaning the
     temporary file up.

 (3) the recipient must walk and carefully grab the path, certainly
     has to "deal with separator (\n or NUL?) or escaping" anyway,
     especially if the reason you use a temporary index is because
     "they can use ls-files on it".  They need to read from ls-files
     anyway, so that is no better than feeding ls-files compatible
     input from the standard input of the hook script.

no?