Hi, On Wed, Dec 2, 2009 at 1:49 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > ... and if the current buffer isn't the first one, what do we do? > [snip] > What will this result in? A failed request, then the user increases > http.postBuffer, and re-runs the entire command? I am not suggesting the > code should do it differently (e.g. retry with a larger buffer without > having the user to help it). At least not yet. That is why my first > question above was "what do we do?" and not "what should we do?". I guess that by "we" you're referring to the "normal" users of git? > I am primarily interested in _documenting_ the expected user experience in > the failure case, so that people can notice the message, run "git grep" to > find the above line and then run "git blame" to find the commit to read > its log message to understand what is going on. Yes, the code will just fail. As you might suspect, the code won't attempt to mitigate the failure by doing anything, and would require intervention on the part of the user. What the user could do to make this work: 1. Turn off multi-pass authentication and just go with Basic. 2. Allow for persistent curl sessions. In theory, we get a 401 the first time when we send a GET for info/refs; subsequently, curl knows what authentication to use, so the POST request *should* take place without the need for rewinding. In theory. 3. Increase http.postBuffer size in the config. -- Cheers, Ray Chuan -- 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