From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: [PATCH 0/11] Updated 'quickfetch' series
Date: Fri, 9 Nov 2007 06:06:00 -0500 [thread overview]
Message-ID: <20071109110600.GR14735@spearce.org> (raw)
So what started out as a 1 patch hack has now grown into an 11
patch series. *sigh*
1) Fix memory leak in traverse_commit_list
This one seems obvious to me. No real harm to not having it but
later on we'd see the downside to the leak in git-fetch.
2) Reorganize the object memory pools so we can release them
3) Define free_all_objects to deallocate object pools
4) Allow pooled nodes to be recycled back onto a free list
5) Bulk allocate struct commit_list, as we do for struct commit
This part of the series is only lightly tested thus far. It rewrites
the object allocators in alloc.c to allow complete destruction of
the object hash and its contents in a single call. This way we
can rerun the revision machinary a second time in the same process
without the mess of clear_commit_flags() or worring about parents
having been rewritten.
We also decrease memory usage by moving struct commit_list into the
pool of things managed by alloc.c. Given how many of these suckers
we are allocating (3x as many as commits in a --topo-order!) the
malloc overhead saved per parent pointer is probably worth the pain
of reviewing this series.
6) git-fetch: Release objects used by a prior transport
Makes use of the above to ensure transports that are called directly
in-process (e.g. fetch-pack) don't get confused by a prior invocation
of that same transport. I don't think fetch-pack was meant to be
run twice in the same process...
7) git-fetch: Limit automated tag following to only fetched objects
Rewrites the rules behind automated tag following. The new rule is
simpler to understand, has some measure of safety attached to it, and
actually works when we turn on quickfetch behavior in a transport.
8) run-command: Support sending stderr to /dev/null
9) rev-list: Introduce --quiet to avoid /dev/null redirects
10) git-fetch: avoid local fetching from alternate (again)
11) git-fetch: test avoiding unnecessary copying from alternates
Turn on quickfetch for the native git transport. As I'm sitting
here writing this I'm wondering if the quickfetch thing shouldn't
be higher up, like in git-fetch itself, so that we can also use
it in the HTTP transport. But it should work now with the earlier
stuff out of the way.
--
Shawn.
reply other threads:[~2007-11-09 11:06 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20071109110600.GR14735@spearce.org \
--to=spearce@spearce.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).