On 06/27, Junio C Hamano wrote: > Brandon Williams <bmw...@google.com> writes: > > >> > + * 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? > > > > Ok so should I change the server part to "MUST NOT" and the client part > > to "SHOULD"? And I can add code to die when we see refs that weren't > > requested, but i feel like if we add an ability to request a pattern in > > the future this will completely change, which is why I currently have a > > client just ignoring anything else. > > I did not have enough information to give an answer to "should I do > X?"; that is why I asked these questions prefixed with "Just being > curious". I do not quite get a good feeling that I now know enough > to answer, still, but let me try. > > If we anticipate backward incompatible changes between this early > WIP stage and the final completed protocol, it would be GOOD to make > sure that an early WIP clients/servers fail when seeing the other > side gives them something they do not understand, no? > > So...
Yeah after thinking more about this I agree, we should have the client fail out and require that the server MUST not send additional refs. This can of course be loosened through a capability if we want to do something else in the future. Thanks for sanity checking me :) -- Brandon Williams
