From: Andreas Ericsson <ae@op5.se>
To: Jon Smirl <jonsmirl@gmail.com>
Cc: David Tweed <david.tweed@gmail.com>,
"Shawn O. Pearce" <spearce@spearce.org>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Calculating tree nodes
Date: Tue, 04 Sep 2007 07:55:45 +0200 [thread overview]
Message-ID: <46DCF361.2090402@op5.se> (raw)
In-Reply-To: <9e4733910709032252x1fe6f436wdd13bcb1a6f76636@mail.gmail.com>
Jon Smirl wrote:
> On 9/4/07, David Tweed <david.tweed@gmail.com> wrote:
>> On 9/4/07, Jon Smirl <jonsmirl@gmail.com> wrote:
>>> Git has picked up the hierarchical storage scheme since it was built
>>> on a hierarchical file system.
>> FWIW my memory is that initial git used path-to-blob lists (as you're
>> describing but without delta-ing) and tree nodes were added after a
>> couple of weeks, the motivation _at the time_ being they were a
>> natural way to dramatically reduce the size of repos.
>>
>> One of the nice things about tree nodes is that for doing a diff
>> between versions you can, to overwhelming probability, decide
>> equality/inequality of two arbitrarily deep and complicated subtrees
>> by comparing 40 characters, regardless of how remote and convoluted
>> their common ancestry. With delta chains don't you end up having to
>> trace back to a common "entry" in the history? (Of course, I don't
>> know how packs affect this - presumably there's some delta chasing to
>> get to the bare objects as well.)
>
> While it is a 40 character compare, how many disk accesses were needed
> to get those two SHAs into memory?
>
One more than there would have been to read only the commit, and one more
per level of recursion, assuming you never ever pack your repository.
If you *do* pack it, the tree(s) needed to compare are likely already
inside the sliding packfile window. In that case, there are no extra
disk accesses.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
next prev parent reply other threads:[~2007-09-04 5:55 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-04 2:13 Calculating tree nodes Jon Smirl
2007-09-04 2:51 ` Shawn O. Pearce
2007-09-04 3:26 ` Jon Smirl
2007-09-04 3:40 ` Johannes Schindelin
2007-09-04 3:54 ` Jon Smirl
2007-09-04 4:21 ` Martin Langhoff
2007-09-04 5:37 ` Jon Smirl
2007-09-04 5:51 ` Andreas Ericsson
2007-09-04 10:33 ` Johannes Schindelin
2007-09-04 14:31 ` Jon Smirl
2007-09-04 15:05 ` Johannes Schindelin
2007-09-04 15:14 ` Andreas Ericsson
2007-09-04 21:02 ` Martin Langhoff
2007-09-04 4:28 ` Junio C Hamano
2007-09-04 5:50 ` Jon Smirl
2007-09-04 4:19 ` David Tweed
2007-09-04 5:52 ` Jon Smirl
2007-09-04 5:55 ` Andreas Ericsson [this message]
2007-09-04 6:16 ` Shawn O. Pearce
2007-09-04 14:19 ` Jon Smirl
2007-09-04 14:41 ` Andreas Ericsson
2007-09-04 6:16 ` David Tweed
2007-09-04 6:26 ` Shawn O. Pearce
2007-09-04 17:39 ` Junio C Hamano
2007-09-06 3:20 ` Shawn O. Pearce
2007-09-06 5:21 ` Junio C Hamano
2007-09-04 16:20 ` Daniel Hulme
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=46DCF361.2090402@op5.se \
--to=ae@op5.se \
--cc=david.tweed@gmail.com \
--cc=git@vger.kernel.org \
--cc=jonsmirl@gmail.com \
--cc=spearce@spearce.org \
/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.