From: Justin Tobler <jltobler@gmail.com>
Date: Wed, 05 Nov 2025 00:17:05 GMT
Subject: Re: [RFC PATCH] diff: add option to report binary files in raw diffs
Message-ID: <nxl3sgs3h2psylifnbwcjmubdfmfhj53jjun5nsa4aqq5robh7@quga463ajvbu>
In-Reply-To: <xmqqzf92quen.fsf@gitster.g>

On 25/11/03 08:44PM, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
> 
> > Justin Tobler <jltobler@gmail.com> 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

> Extending beyond 2-way diff is still something we would need to
> think about, I guess, but the only thing we need to do may be to
> allow N-letter tuples instead of limiting ourselves to 2-letter
> pairs, perhaps?

Ya, for combined diffs I think we could just add another letter for each
source? Something like:

  $ git diff-tree -c --raw-extended=binary <merge commit>
  ::100644 100644 100644 f38991c02a 2defd2d465 54f409c249 MM      foo
  binary=yyy

I think it would be reasonable to expect that each extension mode
(binary, incomplete, crlf, etc) would want to check the commit and each
of its sources.

Thanks for the feedback :)

-Justin