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

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jul 7, 2009, 22:28 UTC
Message-ID: <20090707222820.GC11191@spearce.org>
In-Reply-To: <7vk52k9lvw.fsf@alter.siamese.dyndns.org>

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

Show 13 quoted lines

> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >> 
> >> > * jh/notes (Sat May 16 13:44:17 2009 +0200) 5 commits
> >
> > 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
> 
> Is the idea to make the tree object we need to scan for that particular
> SHA-1 hash smaller?

No, the idea was to avoid needing to create a massive hash of all commit notes just to answer `git log -10` on the current branch. I remember that was a concern last time we were talking about this. By putting the notes under a timestamped path we can scan only a small percentage of the notes before we have sufficient data to output the first few commits.

> 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.

See above, the idea is to avoid scanning all notes at once on
startup.  SHA-1 is bad at this as a fanout because it is too good
at uniform distribution of the names.

> But probably I am missing something.
> 
> Besides, trees and blobs cannot be annotated with that approach.

True.  But I didn't realize that was a goal.  :-|

-- 
Shawn.