Duy Nguyen <pclouds@xxxxxxxxx> writes:
> 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?
