From: Patrick Steinhardt <ps@pks.im>
To: Toon Claes <toon@iotcl.com>
Cc: git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH v2] combine-diff: don't override recursive flag in diff_tree_combined()
Date: Thu, 18 Sep 2025 07:49:31 +0200 [thread overview]
Message-ID: <aMuda6sqEiwxxAgp@pks.im> (raw)
In-Reply-To: <87ecs6o21e.fsf@iotcl.com>
On Tue, Sep 16, 2025 at 05:22:21PM +0200, Toon Claes wrote:
> Patrick Steinhardt <ps@pks.im> writes:
> > Do we know to set `diffopt.flags.recursive` in that case already,
> > or do we handle recursion manually in that case?
>
> git-last-modified sets that flag when `-r` or `--recursive` is given.
> That flag is passed down to diff_tree_combined(), which reuses that
> value (and no longer overrided it). Does that answer your question?
Yup, it does.
> >> diff --git a/combine-diff.c b/combine-diff.c
> >> index 3878faabe7bb2f7c80cffbf3add6123f17960627..305414efdf436d53fee8d79aa4219f6a4dd3445e 100644
> >> --- a/combine-diff.c
> >> +++ b/combine-diff.c
> >> @@ -1515,7 +1515,6 @@ void diff_tree_combined(const struct object_id *oid,
> >>
> >> diffopts = *opt;
> >> copy_pathspec(&diffopts.pathspec, &opt->pathspec);
> >> - diffopts.flags.recursive = 1;
> >> diffopts.flags.allow_external = 0;
> >>
> >> /* find set of paths that everybody touches
> >
> > With the above I'm a bit worried that we're changing behaviour for
> > direct or indirect callers without noticing. Our tests may not detect
> > any regressions, but that doesn't really prove that there is none.
>
> As I've been trying to explain in the first version[1] of my patch, I
> would say my change fixes a bug. Agreed, it's an ancient old bug, I
> still consider it a bug. I think in practice no one will notice this
> change in behaviour, because otherwise they would have complained about
> the buggy behaviour.
>
> For the callsites we didn't address, I'm doubtful anyone will notice a
> change. Also, as I'm laying out above, we only see a bug in rare edge
> cases. That's also why we don't see any test failures.
>
> So yes, there might be a change in behaviour, but it will be correct and
> barely anyone will notice.
>
> Unfortunately I don't have any data to prove this.
The old code certainly feels fishy, that much I can say. Other than that
I'm not knowledgeable enough in this code area to have an informed
opinion. The old mailing list thread [1] doesn't surface any useful
info, either.
Patrick
[1]: https://lore.kernel.org/git/7vwtgqas0y.fsf@assigned-by-dhcp.cox.net/
next prev parent reply other threads:[~2025-09-18 5:49 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-05 13:06 [PATCH v2] combine-diff: don't override recursive flag in diff_tree_combined() Toon Claes
2025-09-05 15:27 ` Junio C Hamano
2025-09-05 15:37 ` Kristoffer Haugsbakk
2025-09-08 12:19 ` Toon Claes
2025-09-16 7:11 ` Patrick Steinhardt
2025-09-16 15:22 ` Toon Claes
2025-09-18 5:49 ` Patrick Steinhardt [this message]
2025-09-18 8:00 ` [PATCH v3] last-modified: fix bug when some paths remain unhandled Toon Claes
2025-09-18 15:18 ` Junio C Hamano
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=aMuda6sqEiwxxAgp@pks.im \
--to=ps@pks.im \
--cc=chriscool@tuxfamily.org \
--cc=git@vger.kernel.org \
--cc=toon@iotcl.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).