Re: http-protocol question

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Dec 2, 2014, 05:17 UTC
Message-ID: <20141202051755.GA6527@google.com>
In-Reply-To: <CAGyf7-Gx1VU-1OicCHG0sStUnNXy_0Y8VYUP+PZjpN6nz7dTrw@mail.gmail.com>

Bryan Turner wrote:

> I ask because it's actually happening. Heavy CI load sometimes has
> builds fail because git clone dies with "not our ref". That's the
> specific context I'm working to try and address right now.

Thanks --- that makes sense.

Show 6 quoted lines

>                                                            Some teams
> use rebase-heavy workflows, which also evades the check_non_tip easing
> and fails with "not our ref", so I can't be 100% certain it's ref
> deletion in specific causing it (but I guess which of those it is is
> probably largely academic; as long as hosting spans multiple requests
> it seems like this type of race condition is unavoidable).

Yeah, everything mentioned before about ref deletion also applies to non-fast-forward updates.

> I'm trying to decide if there is something I can enable or tune to
> prevent it, and the type of twilighting hinted at by the http-protocol
> documentation seemed like it could be just the thing.

If you control the side that clones, then just cloning the single branch you are building (with --single-branch and -b) can help.

Using a bidirectional protocol like git:// or ssh:// (where the ref advertisement and check of wants happen in the same connection) would avoid the problem we're talking about.

On the server side, I agree that either mining reflogs or storing advertisements to disk would be a nice way to take care of this. No one has implemented either of those, but it would be a nice setting to have. :)

Thanks, Jonathan