Re: [REVISED PATCH 2/6] Introduce commit notes

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Jul 19, 2007, 17:20 UTC
Message-ID: <alpine.LFD.0.999.0707191013440.27353@woody.linux-foundation.org>
In-Reply-To: <7vfy3l3rj0.fsf@assigned-by-dhcp.cox.net>

On Wed, 18 Jul 2007, Junio C Hamano wrote:

> 
> Another anchoring clue you seem not to be exploiting fully is
> that the ASCII part must match "^[1-7][0-7]{4,5} " (mode bytes).

I did that on purpose.

The SHA1 *can* contain those characters too, so that's not really useful to us, and the only special character really is the NUL character (which is the only one cannot exists in the ASCII part - old-style trees can contain '/' too, although that's going away).

Also, the mode bytes may not be visible: if we start in a long filename, we'll never have looked at the mode bytes, but if we see a NUL character after having seen 20 non-NUL characters (long filename), we already know we got it. So I don't think we can even usefully use the other knowledge of the format of the ASCII part (other than to know it doesn't contain NUL's).

Of course, we can (and should) verify that the tree entry we find is valid, and *then* it makes sense to check the rules for the ASCII part. But that's only after we have already found the place.

> I was suggesting to have a specialized parser only to read such
> tree objects that are "abused" to represent notes.  You can
> cheaply validate that these trees are of expected shape.

Sure. That said, I'm less interested in the notes than I am in the cost fo "git blame", and that could be optimized by having some special code in "tree_entry_interesting()" to find the tree entries using binary search.

The special code would trigger only for:
 - large trees
 - "opt->nr_paths == 1"

but the latter case is the one that matters for blame in the first place, so..

		Linus