On Fri, Feb 16, 2024 at 09:56:14PM -0800, Junio C Hamano wrote: > > 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. I think we are mostly on the same page, but just to be pedantic: I do not think even adding a "*" attribute in the notes tree could ever do anything. The "git show" invocation is not "git show notes_ref:<path>". We resolve the note blob to an oid, and then pass that oid's hex to "git show". So the "git show" command itself has no context at all, and does not even know this blob came from a tree in the first place. -Peff
