[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:       "Shawn O. Pearce" <spearce () spearce ! org>
Date:       2009-07-07 22:28:20
Message-ID: 20090707222820.GC11191 () spearce ! org
[Download RAW message or body]

Junio C Hamano <gitster@pobox.com> wrote:
> "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.
--
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]