From: Justin Tobler Date: Fri, 07 Nov 2025 17:16:35 GMT Subject: Re: [RFC PATCH] diff: add option to report binary files in raw diffs Message-ID: In-Reply-To: <20251107083015.GA18670@tb-raspi4> On 25/11/07 09:30AM, Torsten Bögershausen wrote: > On Thu, Nov 06, 2025 at 03:42:49PM -0600, Justin Tobler wrote: > > On 25/11/05 12:04AM, Junio C Hamano wrote: > > > Justin Tobler writes: > > Currently the output in the next version will look like: > > > > :100644 100644 a1961526 e231acb1 binary=yy M foo > > :100644 100644 31eedd5c 402a70d7 binary=nn M bar > > > > I think that is a good solutution ;-) > When I once developped the > git ls-files --eol option someone (Junio ?) convinced my to > use a TAB as a seperator. > In this case just before the filename: > > git ls-file --eol | xxd > 00000000: 692f 6c66 2020 2020 772f 6c66 2020 2020 i/lf w/lf > 00000010: 6174 7472 2f20 2020 2020 2020 2020 2020 attr/ > 00000020: 2020 2020 2020 092e 6369 7272 7573 2e79 ..cirrus.y > ^^ > 00000030: 6d6c 0a ml. > > This makes the output both human readable and machine parsable: > All info is before the TAB here. (And may be parsed again in a second > round, if needed). > Thoughts ? So the raw diff format for a normal diff pair is as follows: :SPSPSPSP[score]TAB[TAB]LF When the `-z` option is used, tab and LF are replaced with a NUL byte. So we do already use a tab to delimit between the score/paths. If we wanted to drop avoid using comma to delimit between extended raw diff output we could use a space instead and use TAB to indicate the end. Maybe something like: :100644 100644 a1961526 e231acb1 binary=yy crlf=nn M foo :100644 100644 31eedd5c 402a70d7 binary=nn crlf=yy M bar 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. :) Thanks, -Justin