All of lore.kernel.org
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Justin Tobler <jltobler@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] docs: clarify git-rev-list(1) --filter behavior
Date: Tue, 16 Dec 2025 15:49:16 +0100	[thread overview]
Message-ID: <aUFxbDPucKr42fIJ@pks.im> (raw)
In-Reply-To: <xnstt6myzzfyq65w73xuqg7cfso3bdw6tw33shrery4e4gi2zy@pfxq2pjmb2hm>

On Tue, Dec 16, 2025 at 08:36:56AM -0600, Justin Tobler wrote:
> On 25/12/16 09:12AM, Patrick Steinhardt wrote:
> > On Tue, Dec 16, 2025 at 10:13:22AM +0900, Junio C Hamano wrote:
> > > > diff --git a/Documentation/rev-list-options.adoc b/Documentation/rev-list-options.adoc
> > > > index d9665d82c8..453ec59057 100644
> > > > --- a/Documentation/rev-list-options.adoc
> > > > +++ b/Documentation/rev-list-options.adoc
> > > > @@ -983,7 +983,9 @@ to name units in KiB, MiB, or GiB.  For example, `blob:limit=1k`
> > > >  is the same as 'blob:limit=1024'.
> > > >  +
> > > >  The form `--filter=object:type=(tag|commit|tree|blob)` omits all objects
> > > > -which are not of the requested type.
> > > > +which are not of the requested type. Note that explicitly provided objects
> > > > +ignore filters and are always printed unless `--filter-provided-objects` is
> > > > +also specified.
> > > 
> > > The above documents the status quo correctly, so let's queue, but it
> > > is unfortunate that we need an extra option to do this.
> > 
> > True. I didn't feel comfortable to change the default to also filter
> > provided objects when I discovered that we don't, hence the new option.
> > It's not great though as it certainly is surprising behaviour, but I'm
> > not sure whether we can really change it without breaking existing
> > users. Oh, well...
> 
> Out of curiousity, are there any known use-cases where a user _would_
> want the provided objects printed along with the filtered ones? From my
> naive perspective it almost doesn't even sound useful and appears to
> just be a sharp edge. This maybe not worthing worrying too much about
> though.

I don't really have an idea, but that's exactly the problem here.
Filters are for example used by partial clones, and I don't want to
break those because I'm not aware of some of the intricacies. Which
doesn't mean that there _are_ use cases where this is actually the
desired behaviour, but rather that there needs to be some research to
come to a conclusion here.

Patrick

  reply	other threads:[~2025-12-16 14:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-15 20:05 [PATCH] docs: clarify git-rev-list(1) --filter behavior Justin Tobler
2025-12-16  1:13 ` Junio C Hamano
2025-12-16  8:12   ` Patrick Steinhardt
2025-12-16 14:36     ` Justin Tobler
2025-12-16 14:49       ` Patrick Steinhardt [this message]
2025-12-16 18:07       ` 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=aUFxbDPucKr42fIJ@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jltobler@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.