Re: http-protocol question

From: Bryan Turner <bturner@atlassian.com>
Date: Dec 2, 2014, 05:47 UTC
Message-ID: <CAGyf7-FDRS_zGQSFKhV8UGfN5GjGcyo0yCz8bcjEALYF3oj=Bg@mail.gmail.com>
In-Reply-To: <20141202053331.GA31516@peff.net>

On Tue, Dec 2, 2014 at 4:33 PM, Jeff King <peff@peff.net> wrote:

Show 18 quoted lines

> On Tue, Dec 02, 2014 at 04:04:11PM +1100, Bryan Turner wrote:
>
>> > Can you say more about the context?  For example, was this actually
>> > happening, or is this for the sake of understanding the protocol
>> > better?
>>
>> 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. 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).
>
> There is a practical reason to care. Ref deletion will also delete the
> reflog, leaving no trace of the reachability. Whereas a non-fast-forward
> push could be resolved by looking in the reflog.

A fair point. I had mistakenly thought that reflogs would survive the ref's deletion and be "pruned" as part of garbage collection, but a quick test shows that, as I'm sure you already know, that's not true.

Thanks for correcting my mistake! Bryan Turner