From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Lidong Yan <yldhome2d2@gmail.com>,
git@vger.kernel.org, hi@arnes.space, michal@isc.org
Subject: Re: [PATCH] diff: ensure consistent diff behavior with -I<regex> across output formats
Date: Mon, 4 Aug 2025 08:42:18 -0400 [thread overview]
Message-ID: <20250804124218.GA86602@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqtt2nd7k6.fsf@gitster.g>
On Sun, Aug 03, 2025 at 09:39:21PM -0700, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > .... It affects all of raw, name-only,
> > name-status, and checkdiff. I know Junio said that --raw should not be
> > affected, but I'm not sure I agree.
>
> I no longer am sure if I agree. I do not mind a raw entry that
> would show different object name for preimage and postimage for a
> path to be omitted when --ignore-whatever is passed and the blobs
> compare "equal" under the specified "ignore" criteria.
>
> The behaviour sounds somewhat incoherent, but that is what the user,
> who passes both --raw and --ignore-whatever to the command at the
> same time, wants.
Yeah, exactly. It definitely is weird, but it feels like the closest
thing to what the user asked for.
Just trying to play devil's advocate on this whole topic: is there
anybody who could complain about omitting these entries from raw or
name-only lists? IMHO it is weird and a bug that:
git diff --name-only --raw -p -w <commit...>
might show an entry in the name-only and raw lists that doesn't also end
up in the actual patch. For just:
git diff --name-only --raw -w
it is easy to say "well, why did you pass -w if you did not want
content-level inspection?". But when they are combined, could the
current behavior ever be preferred?
The two counterpoints I can think of are:
1. Maybe that is an interesting signal to somebody that the diff _did_
touch that path, but it just had no content-level change. I am
having trouble imagining why that is useful, but it's not outside
the realm of possibility. And certainly you could get that
information separately by running a tree-level raw diff (without
"-w") followed by a "-p -w" diff (and if you use diff-pairs, that
second diff can even skip doing the tree-diff again).
2. 99% of the time, "-w" (or -I, or whatever) will not remove the
entirety of the change from those files. So we will do a whole
content-level diff just to say "yep, we still should mention this
in --raw"). Is the extra computation worth it?
-Peff
next prev parent reply other threads:[~2025-08-04 12:42 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-23 5:47 git-diff: --ignore-matching-lines has no effect on the output when --name-only is used hi
2025-07-23 8:00 ` Lidong Yan
2025-07-23 17:09 ` Junio C Hamano
2025-07-24 1:56 ` Lidong Yan
2025-07-24 2:16 ` Eric Sunshine
2025-07-24 3:38 ` Lidong Yan
2025-07-25 6:00 ` hi
2025-07-25 6:06 ` hi
2025-07-25 6:46 ` Lidong Yan
2025-07-25 8:08 ` hi
2025-07-25 11:11 ` Jeff King
2025-07-25 15:20 ` Junio C Hamano
2025-07-29 8:18 ` [PATCH] diff: ensure consistent diff behavior with -I<regex> across output formats Lidong Yan
2025-07-30 0:28 ` Junio C Hamano
2025-08-02 10:22 ` Jeff King
2025-08-03 8:42 ` Lidong Yan
2025-08-03 15:43 ` Junio C Hamano
2025-08-04 4:39 ` Junio C Hamano
2025-08-04 12:42 ` Jeff King [this message]
2025-08-03 14:51 ` [PATCH v2] " Lidong Yan
2025-08-04 0:39 ` Junio C Hamano
2025-08-04 1:56 ` Lidong Yan
2025-08-04 4:36 ` Junio C Hamano
2025-08-05 9:23 ` Lidong Yan
2025-08-05 16:11 ` Junio C Hamano
2025-08-06 12:33 ` [PATCH v3] diff: ensure consistent diff behavior with ignore options Lidong Yan
2025-08-06 17:35 ` Junio C Hamano
2025-08-07 1:23 ` Lidong Yan
2025-08-06 20:56 ` Junio C Hamano
2025-08-07 1:39 ` Lidong Yan
2025-08-07 2:06 ` [PATCH v4] " Lidong Yan
2025-08-07 21:27 ` Junio C Hamano
2025-08-08 1:46 ` Lidong Yan
2025-08-08 3:30 ` [PATCH v5] " Lidong Yan
2025-10-16 14:55 ` Johannes Schindelin
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=20250804124218.GA86602@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=hi@arnes.space \
--cc=michal@isc.org \
--cc=yldhome2d2@gmail.com \
/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).