All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>, git@vger.kernel.org
Subject: Re: What's cooking in git.git (Jul 2009, #01; Mon, 06)
Date: Tue, 7 Jul 2009 15:28:20 -0700	[thread overview]
Message-ID: <20090707222820.GC11191@spearce.org> (raw)
In-Reply-To: <7vk52k9lvw.fsf@alter.siamese.dyndns.org>

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.

  reply	other threads:[~2009-07-07 22:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-06 18:32 What's cooking in git.git (Jul 2009, #01; Mon, 06) Junio C Hamano
2009-07-06 20:29 ` Marcus Camen
2009-07-06 21:38   ` Junio C Hamano
2009-07-06 22:03     ` Marcus Camen
2009-07-06 22:34       ` Junio C Hamano
2009-07-06 23:42 ` Jakub Narebski
2009-07-07  2:18 ` Mark Lodato
2009-07-07 21:11   ` Jeff King
2009-07-07  6:30 ` Johannes Sixt
2009-07-07 19:17 ` Linus Torvalds
2009-07-07 19:57   ` Alex Riesen
2009-07-07 22:13     ` Linus Torvalds
2009-07-07 20:08 ` Johannes Schindelin
2009-07-07 20:13   ` Shawn O. Pearce
2009-07-07 22:19     ` Junio C Hamano
2009-07-07 22:28       ` Shawn O. Pearce [this message]
2009-07-08 13:42         ` notes, was " Johannes Schindelin
2009-07-08  5:39 ` Stephen Boyd
2009-07-08  6:38 ` Johannes Sixt
2009-07-10  5:05 ` Christian Couder

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090707222820.GC11191@spearce.org \
    --to=spearce@spearce.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.