Jeff King <peff@xxxxxxxx> writes: > Digging in the history, it looks like we use "git show" at all because > this was adapted from a shell script (though that shell script probably > ought to have been using cat-file in the first place; maybe back then we > thought we'd support non-blobs ;) ). Yup, that is why I suspected that we planned to store non-blobs. > Hmm, good question. I can't think offhand of a way that the user could > convince "git show <oid>" to do anything different than just dumping the > literal contents. It is not even handed a path that could trigger > .gitattributes or similar. show_blob_object() directly calls stream_blob_to_fd() without any filter, as the hardcoded invocation of "git show <oid>" in the note codepath does not allow --textconv at all, so we probably are safe to assume that the contents will appear as-is, not even going through EOL conversion (which is a bit puzzling, to be honest, though). Lack of path I am not worried about, as you can easily declare with '*' wildcard that everything in the notes tree is of the same type. But if the stream_blob_to_fd() interface does not have anywhere smudge filters or textconv filters can hook into without some command line option, we do not have to worry about it. > Sometimes, of course, we have to support weird stuff anyway because it > has existed for a long time and we don't want to break users. But this > is really pushing my gut-feeling limit of what is reasonable / plausible > for somebody to be doing. > > Of course I may be missing some other case where "show" behaves in a > useful way that is different than a straight dump of the blob. But if > not, I'd almost say that getting rid of the extra "show" call now is a > good thing, because it locks in the simple behavior. ;) Yes, of course. It would be great if we can just stream the blob contents out in-process. Thanks.
