From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Andy Parkins <andyparkins@gmail.com>,
git@vger.kernel.org, Alberto Bertogli <albertito@gmail.com>,
Johan Herland <johan@herland.net>
Subject: Re: [PATCH 0/6] Introduce commit notes
Date: Mon, 16 Jul 2007 17:26:31 +0100 (BST) [thread overview]
Message-ID: <Pine.LNX.4.64.0707161724110.14781@racer.site> (raw)
In-Reply-To: <7vbqec4vk2.fsf@assigned-by-dhcp.cox.net>
Hi,
On Mon, 16 Jul 2007, Junio C Hamano wrote:
> Andy Parkins <andyparkins@gmail.com> writes:
>
> > On Monday 2007 July 16, Johannes Schindelin wrote:
> >
> >> The biggest obstacle was a thinko about the scalability. Tree
> >> objects take free form name entries, and therefore a binary search by
> >> name is not possible.
> >
> > I might be misunderstanding, but in the case of the notes tree objects
> > isn't it true that the name entries aren't free form, but are
> > guaranteed to be of a fixed length form:
> >
> > XX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
> >
> > In which case you can binary search?
>
> Hmph, you are right. In this sequence:
>
> hex = sha1_to_hex(commit->object.sha1);
> snprintf(name, sizeof(name), "%s:%.*s/%.*s",
> notes_ref_name, 2, hex, 38, hex + 2);
> if (get_sha1(name, sha1))
> return;
>
> Instead, we could read the tree object by hand in the commit that is
> referenced by notes_ref_name, which has uniform two letter names for
> subtrees which can be binary searched, open the tree for that entry,
> again by hand, and do another binary search because that tree has
> uniform 38-letter names. That certainly could be done.
>
> Sounds like a "fun" project for some definition of the word.
I disagree. One disadvantage to using tree objects is that it is much
easier to have pilot errors. You could even make a new working tree
checking out refs/notes/commits and change/add/remove files.
Ciao,
Dscho
next prev parent reply other threads:[~2007-07-16 16:26 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-15 23:19 [PATCH 0/6] Introduce commit notes Johannes Schindelin
2007-07-15 23:22 ` [PATCH 1/6] Rename git_one_line() to git_line_length() and export it Johannes Schindelin
2007-07-15 23:23 ` [PATCH 2/6] Introduce commit notes Johannes Schindelin
2007-07-15 23:36 ` Junio C Hamano
2007-07-15 23:52 ` Johannes Schindelin
2007-07-16 0:05 ` Junio C Hamano
2007-07-16 5:11 ` Junio C Hamano
2007-07-19 2:30 ` [REVISED PATCH " Johannes Schindelin
2007-07-19 3:28 ` Linus Torvalds
2007-07-19 5:13 ` Junio C Hamano
2007-07-19 9:34 ` Junio C Hamano
2007-07-19 9:57 ` Adam Hayek
2007-07-19 10:58 ` Andy Parkins
2007-07-19 11:10 ` Johannes Schindelin
2007-07-19 14:33 ` Andy Parkins
2007-07-19 17:42 ` Linus Torvalds
2007-07-20 0:20 ` Junio C Hamano
2007-07-20 4:59 ` Shawn O. Pearce
2007-07-19 17:20 ` Linus Torvalds
2007-07-19 9:50 ` Johannes Schindelin
2007-07-19 10:34 ` Olivier Galibert
2007-07-19 17:50 ` Linus Torvalds
2007-07-19 9:05 ` Wincent Colaiuta
2007-07-19 9:24 ` Johannes Schindelin
2007-07-19 9:54 ` Sven Verdoolaege
2007-07-15 23:23 ` [PATCH 3/6] Add git-notes Johannes Schindelin
2007-07-16 5:11 ` Junio C Hamano
2007-07-19 2:31 ` [REVISED PATCH " Johannes Schindelin
2007-07-19 2:54 ` Johannes Schindelin
2007-07-15 23:24 ` [PATCH 4/6] Add a test script for "git notes" Johannes Schindelin
2007-07-16 5:11 ` Junio C Hamano
2007-07-19 2:32 ` [REVISED PATCH " Johannes Schindelin
2007-07-15 23:24 ` [PATCH 5/6] Document git-notes Johannes Schindelin
2007-07-15 23:26 ` [WIP PATCH 6/6] notes: add notes-index for a substantial speedup Johannes Schindelin
2007-07-15 23:33 ` Johannes Schindelin
2007-07-16 6:01 ` Shawn O. Pearce
2007-07-16 16:29 ` Johannes Schindelin
2007-07-16 7:57 ` [PATCH 0/6] Introduce commit notes Andy Parkins
2007-07-16 8:11 ` Junio C Hamano
2007-07-16 16:26 ` Johannes Schindelin [this message]
2007-07-16 17:56 ` Junio C Hamano
2007-07-19 1:34 ` Johannes Schindelin
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=Pine.LNX.4.64.0707161724110.14781@racer.site \
--to=johannes.schindelin@gmx.de \
--cc=albertito@gmail.com \
--cc=andyparkins@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johan@herland.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).