On Saturday 14 May 2011, Shawn Pearce wrote: > I wonder... should we instead export the objectCountLimit as part of > the advertisement to the client, and teach send-pack to look at this > and pass it down to pack-objects? If pack-objects winds up with more > than this limit, it aborts and the client doesn't even transmit data. > Newer clients would abort cleanly with a nice error. Good idea (although it grows the scope from the quick-fix I initially intended it to be...) 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 ":") 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. IINM there are only two ways to prevent an older client from transferring all the data: 1. Change the pack protocol in an incompatible way, that causes older client to abort with a pack format error prior to transmitting the pack. 2. (as in initial patch) Abort receive-pack when the server detects a limit violation, leaving the client with a broken pipe. I haven't read the pack protocol closely, but I wouldn't be surprised if this behavior is strictly in violation of the protocol. > In my experience > when a user gets these strange errors from his Git client, he contacts > his server administrator with the screen output. At which point the > administrator can see the Counting objects line, check the repository > configuration, and tell the user what the problem is... and encourage > them to upgrade their client to a newer version. Hmm... Not ideal, but I guess we can live with that. At least we should warn the server administrator of this in the documentation of the config variable(s). Otherwise, I agree with everything you wrote. Have fun! :) ...Johan -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html