Re: [PATCH 0/3] fix unparsed object access in upload-pack

From: Junio C Hamano <gitster@pobox.com>
Date: Mar 17, 2013, 06:17 UTC
Message-ID: <7vk3p6sg7l.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130317054039.GA16070@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 18 quoted lines

>> >   [3/3]: upload-pack: load non-tip "want" objects from disk
>> >
>> >     While investigating the bug, I found some weirdness around the
>> >     stateless-rpc check_non_tip code. As far as I can tell, that code
>> >     never actually gets triggered. It's not too surprising that we
>> >     wouldn't have noticed, because it is about falling back due to a
>> >     race condition. But please sanity check my explanation and patch.
>> 
>> Thanks. That fall-back is Shawn's doing and I suspect that nobody is
>> exercising the codepath (he isn't).
>
> I almost wonder if we should cut it out entirely. It is definitely a
> possible race condition, but I wonder if anybody actually hits it in
> practice (and if they do, the consequence is that the fetch fails and
> needs to be retried). As far as I can tell, the code path has never
> actually been followed, and I do not recall ever seeing a bug report or
> complaint about it (though perhaps it happened once, which spurred the
> initial development?).

If you run multiple servers serving the same repository at the same URL with a small mirroring lag, one may observe a set of refs from one server, that are a tad older than the other server you actually fetch from. k.org may have such an arrangement, but does GitHub serve the same repository on multiple machines without tying the same client to the same backend?