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

[Justin Tobler <jltobler@gmail.com>]

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 <jltobler@gmail.com> 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:

  :<src mode>SP<dst mode>SP<src sha>SP<dest sha>SP<status>[score]TAB<src path>[TAB<dest path>]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