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

From: Junio C Hamano <[email-masked]>
Date: Wed, 17 Dec 2025 03:07:16 +0900

Justin Tobler <[email-masked]> writes:

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