From: Junio C Hamano <gitster@pobox.com>
To: Justin Tobler <jltobler@gmail.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
git@vger.kernel.org, karthik.188@gmail.com
Subject: Re: [RFC PATCH] diff: add option to report binary files in raw diffs
Date: Fri, 07 Nov 2025 09:26:53 -0800 [thread overview]
Message-ID: <xmqqjz01g3du.fsf@gitster.g> (raw)
In-Reply-To: <ikzwvvyyhuhvr7picunl3r4zem4cn566zpjxpmh6u4oq6ncswa@cdfokimobtms> (Justin Tobler's message of "Fri, 7 Nov 2025 11:16:35 -0600")
Justin Tobler <jltobler@gmail.com> writes:
> 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.
next prev parent reply other threads:[~2025-11-07 17:26 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-04 2:14 [RFC PATCH] diff: add option to report binary files in raw diffs Justin Tobler
2025-11-04 2:26 ` Junio C Hamano
2025-11-04 4:44 ` Junio C Hamano
2025-11-05 0:17 ` Justin Tobler
2025-11-05 8:04 ` Junio C Hamano
2025-11-06 21:42 ` Justin Tobler
2025-11-07 8:30 ` Torsten Bögershausen
2025-11-07 16:07 ` Junio C Hamano
2025-11-07 17:16 ` Justin Tobler
2025-11-07 17:26 ` Junio C Hamano [this message]
2025-11-05 12:14 ` Ben Knoble
2025-11-06 21:52 ` Justin Tobler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqjz01g3du.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=jltobler@gmail.com \
--cc=karthik.188@gmail.com \
--cc=tboegi@web.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).