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. > 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 -- 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