On Thu, 22 Feb 2018 10:26:47 -0800
Brandon Williams <bmw...@google.com> wrote:
> On 02/21, Jonathan Tan wrote:
> > On Tue, 6 Feb 2018 17:12:53 -0800
> > Brandon Williams <bmw...@google.com> wrote:
> >
> > > -const struct ref *transport_get_remote_refs(struct transport *transport)
> > > +const struct ref *transport_get_remote_refs(struct transport *transport,
> > > + const struct argv_array
> > > *ref_patterns)
> > > {
> > > if (!transport->got_remote_refs) {
> > > - transport->remote_refs =
> > > transport->vtable->get_refs_list(transport, 0, NULL);
> > > + transport->remote_refs =
> > > + transport->vtable->get_refs_list(transport, 0,
> > > + ref_patterns);
> > > transport->got_remote_refs = 1;
> > > }
> >
> > Should we do our own client-side filtering if the server side cannot do
> > it for us (because it doesn't support protocol v2)? Either way, this
> > decision should be mentioned in the commit message.
>
> If someone wants to add this in the future they can, but that is outside
> the scope of this series.
In that case, also document that this function is allowed to return refs
that do not match the ref patterns.
Unlike in patch 15 (which deals with the interface between the transport
code and transport vtables, which can be changed as long as the
transport code is aware of it, as I wrote in [1]), this may result in
user-visible differences depending on which protocol is used. But after
more thinking, I don't think we're in a situation yet where having extra
refs shown/written are harmful, and if it comes to that, we can tighten
this code later without backwards incompatibility. So, OK, this is fine.
[1]
https://public-inbox.org/git/20180221145639.c6cf2409ce2120109bdd1...@google.com/
