On Fri, Aug 5, 2011 at 13:54, Junio C Hamano <gitster@xxxxxxxxx> wrote: > A request to fetch from a client over smart HTTP protocol is served in > multiple steps. In the first round, the server side shows the set of refs > it has and their values, and the client picks from them and sends "I want > to fetch the history leading to these commits". > > When the server tries to respond to this second request, its refs may have > progressed by a push from elsewhere. By design, we do not allow fetching > objects that are not at the tip of an advertised ref, and the server > rejects such a request. The client needs to try again, which is not ideal > especially for a busy server. > > Teach --allow-non-tip option to upload-pack (which is the workhorse driven > by git-daemon and smart http server interface) that lets it server commits > that are not at the tip of any advertised ref, as long as they are > reachable from advertised refs. > > Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx> > --- > > * I'll leave it to interested parties who are more qualified than I am to > update remote-curl nor http-backend to actually ask upload-pack to use > this new logic ;-) Why a new --allow-non-tip flag? Why not always do this with the existing --stateless-rpc flag? I think the only time it is reasonable to allow a non-tip want line is during the smart HTTP usage where the request has spanned processes and the references may have moved in the interm. Over a git:// or SSH where its the same server process and the refs were cached at startup (and thus cannot move), it isn't reasonable to allow a non-tip want. Otherwise the patch looks good to me. This should fix some issues with very busy repositories being fetched over smart HTTP. -- Shawn. -- 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