From: Shawn Pearce Date: Sat, 06 Aug 2011 21:05:31 GMT Subject: Re: [RFC] helping smart-http/stateless-rpc fetch race Message-ID: In-Reply-To: <7vbow337gx.fsf@alter.siamese.dyndns.org> On Fri, Aug 5, 2011 at 13:54, Junio C Hamano 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 > --- > >  * 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.