[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)
From:       Junio C Hamano <gitster () pobox ! com>
Date:       2009-07-07 22:19:31
Message-ID: 7vk52k9lvw.fsf () alter ! siamese ! dyndns ! org
[Download RAW message or body]

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

> 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.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]