From: Ben Knoble Date: Wed, 05 Nov 2025 12:14:12 GMT Subject: Re: [RFC PATCH] diff: add option to report binary files in raw diffs Message-ID: In-Reply-To: > Le 4 nov. 2025 à 19:17, Justin Tobler a écrit : > > On 25/11/03 08:44PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Justin Tobler writes: >>> >>>> I have a usecase where I would like to know exactly which files in a >>>> diff pair are considered binary by Git when computing diffs. When >>>> computing patch diff output, Git already omits filepair diffs where at >>>> least one side is considered binary and prints a "binary files differ" >>>> message instead. From this message we cannot discern exactly which files >>>> were considered binary by Git though. >>> >>> I have a usecase where I would like to know exactly which side of a >>> diff filepair ends in an incomplete line in a concise format. >>> >>> Should we add yet another column to the raw output to indicate who >>> is complete and who is incomplete? >>> >>> Where does it lead us and when will it stop? >>> >>> IOW, yuck ;-). >> >> My point being that it will be a huge mistake to do this only by >> singling a trait that is not so special as if it is very special, >> only because you have been thinking about it too long (the "ends in >> an incomplete line" trait is what has been on my mind for the past >> few days, "this side is binary" may be what you've been thinking >> about). There are many other things people would want to learn >> concisely in machine readable format, like "where did the file stop >> using CRLF line endings and swithced to LF line endings", that are >> equally plausible as the question you are asking, or the question I >> would be asking "which commit lost the final newline?" > > Completely fair. Having a bunch specific options for special info we > want to add to the raw diff format would get messy quickly and is not > very extensible. > >> Perhaps an extensible command line option syntax like >> >> $ git log --raw-extended=binary,incomplete,crlf,... > > I quite like this and agree it would be better to have a single > extensible option. > >> is in order, and the presense of these options would add "tt,ic,cl" >> somewhere in the output to signal that both sides are text, preimage >> ends in an incomplete line but not postimage, and preimage uses crlf >> but postimage uses lf, or something? > > Maybe the output should be something like: > > binary=tt,incomplete=ic,crlf=cl > > or something along those lines. That way we could freely extend in the > future without having to worry about a specific order. If we think all > of the raw diff extension modes would only report with yes/no for each > file we could just do: > > binary=yn,incomplete=yy,crlf=nn > > but maybe we should be more flexible and leave it up to the mode to > decide what its values can be? > > Also, maybe this info could be on a newline following each raw diff > entry? Something like: > > :100644 100644 a1961526 e231acb1 M foo > binary=yy > :100644 100644 31eedd5c 402a70d7 M bar > binary=nn > Whether combined or separate, self-documenting output is nice. Separate might be easier for line-oriented tools? Having to split on commas and loop looking for keywords seems like more work than just processing a line at a time. Idk.