Jeff King <p...@peff.net> writes:
>> > [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?
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html