Re: [PATCH v4 6/6] list-objects-filter: implement filter tree:0

From: Matthew DeVore <matvore@google.com>
Date: Aug 15, 2018, 17:54 UTC
Message-ID: <CAMfpvhJA3h8cFB_Weh_cDdqQBHccYfCrjs-S-T_nyDG=JVi6Tg@mail.gmail.com>
In-Reply-To: <xmqqr2izk3j0.fsf@gitster-ct.c.googlers.com>

On Wed, Aug 15, 2018 at 9:17 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 19 quoted lines

>
> Jeff King <peff@peff.net> writes:
>
> > Right, I'd agree they probably want the minimum for that traversal. And
> > for `rev-list --filter`, that's probably OK. But keep in mind the main
> > goal for --filter is using it for fetches, and many servers do not
> > perform the traversal at all. Instead they use reachability bitmaps to
> > come up with the set of objects to send. The bitmaps have enough
> > information to say "remove all trees from the set", but not enough to do
> > any kind of depth-based calculation (not even "is this a root tree").
>
> If the depth-based cutoff turns out to make sense (on which I
> haven't formed an opinion yet), newer version of pack bitmaps could
> store that information ;-)
>
> How are these "fitler" expressions negotiated between the fetcher
> and uploader?  Does a "fetch-patch" say "am I allowed to ask you to
> filter with tree:4?" and refrain from using the option when
> "upload-pack" says "no"?

I couldn't find a feature like that for the existing features, but adding such a think seems reasonable to me. (thinking in terms of protocol v2,) There could be a filter-check command which takes a single argument: the filter string (like "tree:4"), and responds with a single line: either "ok" or "unsupported".