Re: [PATCHv2 2/2] receive-pack: Add receive.objectCountLimit to refuse push with too many objects

> On Sat, May 14, 2011 at 06:17, Johan Herland <johan@herland.net> wrote:
> > I'm planning to add a new capability collection/namespace, called
> > "limit-*", where the server can communicate capabilities to the
> > client, like so:
> > 
> >  limit-object-count_100000
> >  limit-commit-count_1000
> >  limit-pack-size_500000000
> > 
> > (I'd prefer to s/_/=/ or s/_/:/, but according to pack-protocol.txt, a
> > capability may not contain "=" or ":")
> 
> I forget why = and : are forbidden here. I think its just because we
> wanted the options to be "simple". I agree, I would prefer = here too,
> and probably would have written the patch that way myself. There
> shouldn't be a technical reason why = isn't allowed here. Its just
> documented as being not a good idea because at one time someone wrote
> that down.

> > However, you say:
> >> For older clients that don't know this new advertised capability, they
> >> should fail hard and not transfer all of this data.
> > 
> > AFAICS this is not the case. If a client does not understand a
> > capability, it simply ignores it, and carries on doing its usual
> > thing.
> 
> By this I meant #2 below (the initial patch).

> I don't think its as bad as it sounds. Its not a great user
> experience, sure. And we maybe should also look at changing the
> send-pack code to check the pipe for received data from the remote
> peer if pack-objects dies (today it doesn't)... just in case the
> reason pack-objects died is because an error message was written and
> then the stream was closed.