Re: [PATCH v1 3/5] list-objects-filter: implement composite filters

From: Matthew DeVore <matvore@comcast.net>
Date: May 29, 2019, 15:02 UTC
Message-ID: <20190529150228.GC4700@comcast.net>
In-Reply-To: <xmqqh89e31fg.fsf@gitster-ct.c.googlers.com>

On Tue, May 28, 2019 at 10:59:31AM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> Jeff Hostetler <git@jeffhostetler.com> writes:
> 
> > In the RFC version, there was discussion [2] 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.

Show 6 quoted lines

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

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