Re: [RFC] helping smart-http/stateless-rpc fetch race

From: Shawn Pearce <spearce@spearce.org>
Date: Aug 6, 2011, 21:05 UTC
Message-ID: <CAJo=hJvdMCyU-5wzy0p1r+QJxXU=DJTE+Mu5G6pk9iAwAD51mA@mail.gmail.com>
In-Reply-To: <7vbow337gx.fsf@alter.siamese.dyndns.org>

On Fri, Aug 5, 2011 at 13:54, Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

> 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@pobox.com>
> ---
>
>  * 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.