Re: [PATCH v1 3/5] list-objects-filter: implement composite filters
- Date: Wed, 29 May 2019 08:02:28 -0700
- From: Matthew DeVore <matvore@xxxxxxxxxxx>
- Subject: Re: [PATCH v1 3/5] list-objects-filter: implement composite filters
On Tue, May 28, 2019 at 10:59:31AM -0700, Junio C Hamano wrote:
> Jeff Hostetler <git@xxxxxxxxxxxxxxxxx> writes:
> > In the RFC version, there was discussion  of the wire format
> > and the need to be backwards compatible with existing servers and
> > so use the "combine:" syntax so that we only have a single filter
> > line on the wire. Would it be better to have compliant servers
> > advertise a "filters" (plural) capability in addition to the
This is a good idea and I hadn't considered it. It does seem to make the
repeated filter lines a safer bet than I though.
> > existing "filter" (singular) capability? Then the client would
> > know that it could send a series of filter lines using the existing
> > syntax. Likewise, if the "filters" capability was omitted, the
> > client could error out without the extra round-trip.
> All good ideas.
After hacking the code halfway together to make the above idea work, and
learning quite a lot in the process, I saw set_git_option in transport.c and
realized that all existing transport options are assumed to be ? (0 or 1) rather
than * (0 or more). So "filter" would be the first transport option that is
Even though multiple reviewers have weighed in supporting repeated filter lines,
I'm still conflicted about it. It seems the drawback to the + syntax is the
requirement for encoding the individual filters, but this encoding is no longer
required since the sparse:path=... filter no longer has to be supported. And the
URL encoding, if it is ever reintroduced, is just boilerplate and is unlikely to
change later or cause a significant maintainance burden.
The essence of the repeated filter line is that we need additional high-level
machinery just for the sake of making the lower-level machinery... marginally
simpler, hopefully? And if we ever need to add new filter combinations (like OR
or XOR rather than AND) this repeated filter line thing will be a legacy
annoyance (users will wonder why does repeated "filter" mean AND rather than
one of the other supported combination methods?). Repeating filter lines seems
like a leaky abstraction to me.
I would be helped if someone re-iterated why the repeated filter lines are a
good idea in light of the fact that URL escaping is no longer required to make