On Thu, Aug 29, 2013 at 12:40:16AM -0400, Jason Pyeron wrote:
> > What would it mean to set it on the server? It is the size
> > at which the client decides to use a "chunked"
> To tell the client...
But the server in this case cannot tell it a useful size. Only "whatever
you do, do not chunk".
> Agreed. By then I hope to get our infrastructure team to address the proxies.
> Liking the spool idea below. The other idea would be restrict the size of any
> one transfer. (would that work if a given commit is large than the
I don't think you can do that elegantly. The packfile needs to come up
as a whole, because the server is stateless. The best you could do is to
split the packfile up into small updates of history, and then have the
server receive each (and update the refs) incrementally. But even that
isn't foolproof; it could be that a single large blob object is larger
than the limit.
> > If the server really insists on a content-length header, then
> > we can't ever fix (2). But we could fix (1) by spooling the
> > packfile to disk and then sending from there (under the
> > assumption that you have way more temporary disk space than RAM).
> Hmmm. So if the server says, hey I have a borked infrastructure, please send
> a content length git could spool then.
I'm not sure how the server would say that. It can return a 411, which
it is currently doing, but the git client will have already discarded
the data by that point. So it would have to come during one of the
earlier responses (I guess an extra http header? I surely would not want
to pollute the git protocol with such hackery).
So let's imagine that we figure that part out, and now we can ship a 1G
packfile up in a single POST by spooling it to disk. Do the proxies
actually allow that? Or do they also have a max-size-per-post setting?
If there is a maximum size, we can't get around that. And if it's small
enough, there's no point in spooling, as we can just get by with
tweaking http.postBuffer instead.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html