> Yeah after thinking more about this
I wonder if we have some mental model that we want to teach to the users?
What is the fetch command (using the ref-in-want capability) supposed to do?
* update to the latest state observed by the latest remote talked to?
* update to some approximate state that
On 06/27, Junio C Hamano wrote:
> Brandon Williams 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 abov
Brandon Williams 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
> Brandon Williams 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
On 06/26, Junio C Hamano wrote:
> Brandon Williams 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
Brandon Williams 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".
Currently, while performing packfile negotiation, clients are only
allowed to specify their desired objects using object ids. This causes
a vulnerability to failure when an object turns non-existent during
negotiation, which may happen if, for example, the desired repository is
provided by multipl
7 matches
Mail list logo
