Re: [PATCH] docs: clarify git-rev-list(1) --filter behavior

From: Junio C Hamano <gitster@pobox.com>
Date: Dec 16, 2025, 18:07 UTC
Message-ID: <xmqqbjjy47xn.fsf@gitster.g>
In-Reply-To: <xnstt6myzzfyq65w73xuqg7cfso3bdw6tw33shrery4e4gi2zy@pfxq2pjmb2hm>

Justin Tobler <jltobler@gmail.com> writes:

Show 11 quoted lines

>> 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.

Perhaps there is no good use case (and that is why I hinted that we may want to "fix" it someday).

It however is understandable that nobody noticed it because for the primarily intended use case of "filter", i.e., object transfer into lazy clone, you use commit-ishes to describe a range to be listed/transferred, and you never filter out the commmit objects, perhaps?