From: "Shawn O. Pearce" <spearce@spearce.org>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: [PATCH 0/5] Yet another builtin-fetch round
Date: Wed, 19 Sep 2007 00:49:23 -0400 [thread overview]
Message-ID: <20070919044923.GP3099@spearce.org> (raw)
Another short series for db/fetch-pack, still in pu. Aside from
optimizing the pipeline on the native transport (so we only invoke
the remote process we need once vs. twice) I'm actually now quite
comfortable with this whole series and think it is ready for next.
I'm certainly running it in production, and will be until it is
merged. The performance difference is too big for me (and at least
some of my coworkers) to not be doing so. If there are any specific
reasons why this topic is not ready for next or is unsuitable for
merging please let me know so I can take the time to correct it.
1/5 Rename remote.uri to remote.url within remote handling internals
2/5 Refactor struct transport_ops inlined into struct transport
3/5 Always obtain fetch-pack arguments from struct fetch_pack_args
These three are basic code cleanups for small issues that
bothered me about the original implementation of builtin-fetch.
Now is just as good of a time as any to cleanup the code and make
it more maintainable. I think the overall total line count is
reduced by these three patches.
* Ensure builtin-fetch honors {fetch,transfer}.unpackLimit
* Fix memory leaks when disconnecting transport instances
Fixes two known (but minor) outstanding bugs. At this point
I do not know of any other bugs in builtin-fetch so I would
really appreciate testing reports from other people, especially
those whose uses cases might stray outside of my workflow. Hah,
I did not tell you my workflow. ;-)
--
Shawn.
next reply other threads:[~2007-09-19 4:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-19 4:49 Shawn O. Pearce [this message]
2007-09-20 2:40 ` [PATCH 0/5] Yet another builtin-fetch round Daniel Barkalow
2007-09-20 4:08 ` Junio C Hamano
2007-09-20 5:09 ` Junio C Hamano
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=20070919044923.GP3099@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).