On Tue, Dec 2, 2014 at 3:45 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Hi, > > Bryan Turner wrote: > >> The reason I ask is that there is a race condition that exists where >> the ref advertisement lists refs/heads/foo at abc1234, and then foo is >> deleted before the actual upload-pack request comes in. > > 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). 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. > > I ask because knowing the context might help us give more specific > advice. > > Sometimes when people delete a branch they really want those objects > to be inaccessible *right away*. So for such people, git's behavior > of failing the request unless the objects are still accessible by > some other path is helpful. > > A stateful server could theoretically cache the list of objects they > have advertised for a short time, to avoid clients having to suffer > when something becomes inaccessible during the window between the > upload-pack advertisement and upload-pack request. Or a permissive > server can allow all wants except a specific blacklist (and some > people do that). > > 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