On Wed, Aug 15, 2018 at 9:17 AM Junio C Hamano <gits...@pobox.com> wrote: > > Jeff King <p...@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".
