Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 7, 2009, 22:19 UTC
Message-ID: <7vk52k9lvw.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20090707201326.GB11191@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

Show 26 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>> On Mon, 6 Jul 2009, Junio C Hamano wrote:
>> 
>> > * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits
>> >  - Teach "-m <msg>" and "-F <file>" to "git notes edit"
>> >  - Add an expensive test for git-notes
>> >  - Speed up git notes lookup
>> >  - Add a script to edit/inspect notes
>> >  - Introduce commit notes
>> > 
>> > Dscho asked about the performance implications of this; I do not think I 
>> > saw any progress on that yet...
>> 
>> Neither did I.
>
> I was thinking about this the other day.  We could use a hash of
> the commit timestamp as the top level directory.  E.g. if we take
> the commit time of the commit and convert it to a date string,
> we could make the note path e.g.:
>
>   YYYY/MM/COMMITSHA1
>
> The advantage is we only need to scan and hash the subtrees for
> the range of commits we are currently producing output for.  As we
> go further back in time, we can evict entries for newer dates and
> hash the older dates.

Is the idea to make the tree object we need to scan for that particular SHA-1 hash smaller?

If so, I am not sure how it would help over another approach of say taking the first four hexdigits from the SHA-1 to use as the initial fan-out YYYY, then two hexdigits for the secondary fan-out MM.

But probably I am missing something.

Besides, trees and blobs cannot be annotated with that approach.