On Mon, Apr 30, 2018 at 1:56 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > 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. Yep, I was not happy about this. Which I why I moved to update the hook calling convention to pass pathspec to the hook instead. > (2) it is totally unclear who is responsible for cleaning the > temporary file up. The one that creates it deletes it, which is git. > (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. Err "ls-files compatible input" or "ls-files compatible _output_"? If by input you mean the pathspec we give to ls-files, I agree. If it's standard ls-files --stage output , letting the hook call ls-files lets it select the output format it wants (including the potential json output in the future), which is more flexible. > > no? -- Duy
