From: Johan Herland <johan@herland.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Daniel Barkalow <barkalow@iabervon.org>, git@vger.kernel.org
Subject: Re: [RFC/PATCH 0/3] Teach builtin-clone to pack refs
Date: Sun, 23 Mar 2008 10:49:20 +0100 [thread overview]
Message-ID: <200803231049.20874.johan@herland.net> (raw)
In-Reply-To: <7v8x0agtdn.fsf@gitster.siamese.dyndns.org>
On Sunday 23 March 2008, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
>
> > Although most of the speedup from current "next" is achieved by the
> > builtin-clone work, there is still a considerable additional improvement
> > from writing all refs to a single file instead of writing one file per
> > ref. I expect the performance improvement to be much bigger on platforms
> > with slower filesystem (aka. Windows).
>
> At some point, additional speedups are hidden in the noise.
Yes, however, I bet you'll notice the difference between writing 11000 files on Windows, and writing 1.
Unfortunately, this scenario is not as far fetched as some may think: At $dayjob I'm working on converting old CVS modules with up to ~10 years of history, and some of the resulting repos have ~30000 refs (mostly build tags). Although I'll probably remove the build tags before preparing the repos that most other developers will see, I'll still have to keep the build tags around somewhere, in case devs need to refer to them. And, of course, most devs are still Windows-users. Keeping refs packed is pretty much crucial in this scenario.
> Not writing reflogs is a _different_ behaviour from the previous, but I
> suspect it might even be an improvement. When you have 1000 remote
> branches, probably most of them are not even active.
Exactly my thinking as well. And for those few that _are_ active, you'll still of course get regular reflog entries when they _do_ change.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
prev parent reply other threads:[~2008-03-23 9:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-22 1:10 [RFC/PATCH 0/3] Teach builtin-clone to pack refs Johan Herland
2008-03-22 1:12 ` [RFC/PATCH 1/3] Move pack_refs() and friends into libgit Johan Herland
2008-03-22 1:13 ` [RFC/PATCH 2/3] Prepare testsuite for a "git clone" that packs refs Johan Herland
2008-04-14 6:10 ` Daniel Barkalow
2008-04-14 8:00 ` Johan Herland
2008-04-14 8:02 ` [PATCH 1/4] Incorporate fetched packs in future object traversal Johan Herland
2008-04-14 8:02 ` [PATCH 2/4] Move pack_refs() and friends into libgit Johan Herland
2008-04-14 8:03 ` [PATCH 3/4] Prepare testsuite for a "git clone" that packs refs Johan Herland
2008-04-14 8:04 ` [PATCH 4/4] Teach "git clone" to pack refs Johan Herland
2008-03-22 1:13 ` [PATCH 3/3] " Johan Herland
2008-03-22 1:31 ` Daniel Barkalow
2008-03-23 0:45 ` [RFC/PATCH 0/3] Teach builtin-clone " Junio C Hamano
2008-03-23 9:49 ` Johan Herland [this message]
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=200803231049.20874.johan@herland.net \
--to=johan@herland.net \
--cc=barkalow@iabervon.org \
--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 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).