Johannes Schindelin <johannes.schinde...@gmx.de> writes:
>> > + if (S_ISREG(mode)) {
>> > + struct strbuf strbuf = STRBUF_INIT;
>> > + if (convert_to_working_tree(path, *buf, *size, &strbuf)) {
>> > + free(*buf);
>> > + *size = strbuf.len;
>> > + *buf = strbuf_detach(&strbuf, NULL);
>> > + }
>> > + }
>>
>> When we see a blob that is not ISREG, what is expected to happen?
>> Is it an error?
>
> This is not a user-facing command, therefore we have to trust the caller
> that they know what they are doing.
The caller that knows what s/he is doing would rely on a documented
behaviour out of the command. That behaviour hopefully is an
intuitive and useful one for script writers.
You say
> Quite frankly, as cat-file is not an end-user-facing command, I think it
> is serious overkill to add more testing here.
and I think you would need a serious attitude adjustment here.
Scriptors are also an important class of end-users and cat-file
directly faces them.
Thinking about this one a bit more, as 'cat-file' especially with
the "--filters" option is the lowest-level way for scriptors to
externalize the data stored in Git object database to the
representation used in the outside world (in other words, it would
be a good ingredient if they want to implement what "checkout"
does), I would expect that an intuitive behaviour for
git cat-file --filters HEAD:Makefile >Makefile
git cat-file --filters HEAD:RelNotes >Relnotes
git cat-file --filters HEAD:t >t
to send the requested contents to the standard output stream, but
error out when the result of the command shown above would not
mimick what "checkout" would leave in the filesystem. IOW, the
first one should succeed, the second and the third ones should fail
the same way to signal what is requested cannot be performed to the
script that is calling these commands.
