From 20d84767b72f219277e8c9345d286c8d06b61ffe Mon Sep 17 00:00:00 2001 From: Bryce Kwon Date: Sat, 7 Nov 2026 12:04:43 -1000 Subject: Pin the listing's blame link for a late NUL The listing judges binary by the first 8000 bytes, as git does, while the blame page and the file view look for a NUL anywhere, since one past that window would end a Lua filter's output early. The listing keeps the cheap sniff, because the whole-blob check would inflate every blob it names, so a file whose NUL lies past the window gets a blame link that ends on "Blob is binary". The test pins that trade, so a change to either side has to face it. --- source/ui-tree.c | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'source') diff --git a/source/ui-tree.c b/source/ui-tree.c index b682f3e..f89498a 100644 --- a/source/ui-tree.c +++ b/source/ui-tree.c @@ -270,6 +270,10 @@ static void print_dir_chain(const struct object_id *oid, const char *name, /* * Whether git counts the blob as binary, read through a stream so that only * the bytes buffer_is_binary looks at are inflated, however large the blob. + * The blame page and the file view also count a NUL anywhere in the blob, so + * a file whose first NUL lies past this window is still offered a blame link + * that leads to "Blob is binary". Finding that NUL would mean inflating the + * whole of every blob the listing names. */ static bool blob_starts_binary(const struct object_id *oid) { -- cgit 2.12.1