Re: [PATCH] Introduce light weight commit annotations

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Jun 11, 2007, 10:25 UTC
Message-ID: <Pine.LNX.4.64.0706111122470.4059@racer.site>
In-Reply-To: <7v4plf5qxp.fsf@assigned-by-dhcp.cox.net>

Hi,

On Sun, 10 Jun 2007, Junio C Hamano wrote:

Show 17 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > I do not understand... the entries of a tree object are sorted 
> > alphabetically, right? Including the convention that if one is a 
> > prefix of another, it is "smaller".
> >
> > While I think that the length would not be any problem, the entries' 
> > names of refs/annotations/commit^{tree} are _all_ of length two, and 
> > point to other tree objects. _Those_ tree objects contain _only_ 
> > entries whose names contain exactly 38 characters.
> 
> That is ONLY true if you are introducing a specialized tree
> object parser that knows it is dealing with the tree used in
> your annotation scheme that has entries of uniform size.  In
> such a tree parser, you could bisect or Newton-Raphson a tree
> object data to find an entry more efficiently than for normal
> trees with enries of variable size.

Ouch. That is a real flaw in my proposal. It completely destroys my "I think this will scale just fine" argument.

> If that happens, "refs/annotations/commit:?{40}" format would let you 
> look up an annotation for a given commit much more efficiently than 
> "refs/annotations/commit:??/?{38}", because it would have to open only 
> one tree object, instead of two.

Let me think that one through. At the moment I cannot think of an easy fix.

Ciao, Dscho