Re: [RFC/PATCH 0/2] Speed up fetch with large number of tags

From: Shawn O. Pearce <spearce@spearce.org>
Date: Sep 16, 2009, 23:03 UTC
Message-ID: <20090916230350.GC14660@spearce.org>
In-Reply-To: <7vtyz2wlhm.fsf@alter.siamese.dyndns.org>

Junio C Hamano <gitster@pobox.com> wrote:

Show 14 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> 
> > JGit depends on the fact that the refs list is sorted by the remote
> > peer, and that foo^{} immediately follows foo.  I don't think this
> > has ever been documented, but all sane implementations[1] follow
> > this convention and it may be something we could simply codify as
> > part of the protocol standard.
> >
> > [1] Sane implementations are defined to be what I consider to be
> >     the two stable implementations in deployed use, git.git and JGit.
> 
> There is no strong reason for ordering of refs between themselves
> (i.e. refs/heads/master comes before refs/heads/next) other than the fact
> that we sort and then walk due to packed-refs reasons.

Sorry, I misspoke a bit above.

JGit does not care about the ordering between two refs, e.g. in your master/next example above JGit would accept them in either order just fine. Internally we enforce this by hashing the advertised refs and walking the hash, callers presenting the data for a user must copy to a list and sort by their desired sorting criteria (usually name).

What I meant to say was this:

Show 5 quoted lines

> But emitting tag X and then its peeled representation X^{} immediately
> after it is quite fundamental in the way how anybody sane would implement
> ls-remote.  There is no reason to violate the established order other than
> "I could do so", and in order not to show X and X^{} next to each other,
> you would need _more_ processing.

and right, explicitly placing X^{} away from X means that the sender has to do more work to buffer one of the two values and then show them later. This is pointless other than to piss off any more reasonable implementor.

I think we should formalize this rule of X^{} immediately follows X if peeling is possible, and if not, then X^{} must not appear. We already have a similar rule with packed-refs, although there it is absolutely required by the format.

> Also, you might not have noticed, but my illustration patch was merely
> using it as a hint to optimize, and if the last ref we saw was not X when
> it is turn to handle X^{}, it simply falled back to the original logic,
> iow, the patch never compromised the correctness.

Oh, I missed that. JGit I think flat out panics and disconnects if the remote does this to us. What is the incentive in supporting a broken server with a slower client?

-- 
Shawn.