> Brandon Williams <bmw...@google.com> writes:
>
> > + wanted-refs section
> > + * This section is only included if the client has requested a
> > + ref using a 'want-ref' line and if a packfile section is also
> > + included in the response.
> > +
> > + * Always begins with the section header "wanted-refs".
> > +
> > + * The server will send a ref listing ("<oid> <refname>") for
> > + each reference requested using 'want-ref' lines.
> > +
> > + * The server SHOULD NOT send any refs which were not requested
> > + using 'want-ref' lines and a client MUST ignore refs which
> > + weren't requested.
>
> Just being curious, but the above feels the other way around. Why
> are we being more lenient to writers of broken server than writers
> of broken clients? The number of installations they need to take
> back and replace is certainly lower for the former, which means
> that, if exchanges of unsoliclited refs are unwanted, clients should
> notice and barf (or warn) if the server misbehaves, and the server
> should be forbidden from sending unsolicited refs, no?
I agree - if you were thinking of later relaxing this constraint to
allow the server to supply tag ref information during tag following,
writing "MUST NOT" here is still fine. (We can later change this to "if
'include-tag-ref' is sent, the server MAY send refs which were not
requested, otherwise, the server MUST NOT".)
Both Jonathan Nieder and I also suggested client enforcement [1] - I see
that in patch 8, in receive_wanted_refs(), unrecognized wanted-ref lines
are silently ignored. Maybe at least a warning would be good.
[1]
https://public-inbox.org/git/20180625230310.210182-1-jonathanta...@google.com/
