On Fri, May 15, 2015 at 10:44:50AM +0200, Dennis Kaarsemaker wrote: > > I applied the test from your patch, but couldn't get it to fail even > > with stock git. The test above it shrunk a bit, but I was able to tweak > > yours to generate tags from 2001..100000, which I thought would have > > worked. I suspect it's something silly like the size not being quite > > big enough for the pipe buffer on my system, or something like that. > > Though I couldn't get it to fail even with 200,000 tags, so perhaps it's > > something else. > > The shrinkage in the test above it will actually work around the issue, > as there are now fewer already-fetched tags to negotiate. Either > reverting that shrinkage or executing the new test twice should do the > trick. Ah, right, that makes sense. I was creating the right number of tags, but not with half of them already in the repo when I did the critical fetch. I got it to fail by adding and fetching another 48,000, and then adding and fetching another 50,000 on top of that. Interestingly, with my patch the _first_ fetch fails, that otherwise succeeds with stock git. My patch sets a maximum size on the spool buffer, and we exceed it. I guess 1MB isn't enough for pathological cases. I'm hesitant to let it expand indefinitely for security reasons, but we could probably bump it to 10MB or something. I dunno. I'm not excited about introducing new size restrictions that were not there before. Maybe it's time to implement git-over-websockets. ;) -Peff -- 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