Re: [RFC PATCH] diff: add option to report binary files in raw diffs

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 7, 2025, 17:26 UTC
Message-ID: <xmqqjz01g3du.fsf@gitster.g>
In-Reply-To: <ikzwvvyyhuhvr7picunl3r4zem4cn566zpjxpmh6u4oq6ncswa@cdfokimobtms>

Justin Tobler <jltobler@gmail.com> writes:

Show 13 quoted lines

> or we could maybe move the extended info towards the start of the line
> and leave the remaining bits the same:
>
>   :binary=yy crlf=nn    100644 100644 a1961526 e231acb1 M    foo
>   :binary=nn crlf=yy    100644 100644 31eedd5c 402a70d7 M    bar
>
> With either of these formats, the expectation would be parsers continue
> reading space delimited "key=value" pairs until they encounter a tab. I
> do think this latter format looks a bit nicer and I don't think it would
> meaningfully impact the complexity of the parser. Ultimately, I don't
> feel super strongly one way or the other though. I may go with this last
> format in the next version since it does look a little nicer IMO. I'm
> still very much interested in folks thoughts here though. :)

With this are your parsers/readers still using the output fields that appear in the --raw output? Do they still want the mode bits, or object names in preimage and postimage? Do they need to even look at "M" anymore, as a new file or a removed file would certainly have only a single sign for these additional traits like binary as such a filepair has only one side by definition?

IOW, I am not sure if it is wise to shoehorn the new pieces of information into the --raw format. Existing parsers would not be able to grok the above at all (they do not even see the fields they recognise at the beginning of lines which is where they recognise them as such), so I do not see any good reason to even pretend this to be some extension to an existing --raw format.