On Tue, Dec 2, 2014 at 4:33 PM, Jeff King <peff@xxxxxxxx> wrote: > 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 -- 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