"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html