From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Subject: [PATCH 1/2] fetch: run gc --auto after fetching
Date: Sat, 26 Jan 2013 17:40:38 -0500 [thread overview]
Message-ID: <20130126224038.GA20849@sigill.intra.peff.net> (raw)
In-Reply-To: <20130126224011.GA20675@sigill.intra.peff.net>
We generally try to run "gc --auto" after any commands that
might introduce a large number of new objects. An obvious
place to do so is after running "fetch", which may introduce
new loose objects or packs (depending on the size of the
fetch).
While an active developer repository will probably
eventually trigger a "gc --auto" on another action (e.g.,
git-rebase), there are two good reasons why it is nicer to
do it at fetch time:
1. Read-only repositories which track an upstream (e.g., a
continuous integration server which fetches and builds,
but never makes new commits) will accrue loose objects
and small packs, but never coalesce them into a more
efficient larger pack.
2. Fetching is often already perceived to be slow to the
user, since they have to wait on the network. It's much
more pleasant to include a potentially slow auto-gc as
part of the already-long network fetch than in the
middle of productive work with git-rebase or similar.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin/fetch.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/builtin/fetch.c b/builtin/fetch.c
index 4b5a898..1ddbf0d 100644
--- a/builtin/fetch.c
+++ b/builtin/fetch.c
@@ -959,6 +959,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
struct string_list list = STRING_LIST_INIT_NODUP;
struct remote *remote;
int result = 0;
+ static const char *argv_gc_auto[] = {
+ "gc", "--auto", NULL,
+ };
packet_trace_identity("fetch");
@@ -1026,5 +1029,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
list.strdup_strings = 1;
string_list_clear(&list, 0);
+ run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);
+
return result;
}
--
1.8.0.2.16.g72e2fc9
next prev parent reply other threads:[~2013-01-26 22:41 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-26 22:40 [PATCH 0/2] optimizing pack access on "read only" fetch repos Jeff King
2013-01-26 22:40 ` Jeff King [this message]
2013-01-27 1:51 ` [PATCH 1/2] fetch: run gc --auto after fetching Jonathan Nieder
[not found] ` <87bmopzbqx.fsf@gmail.com>
2017-07-12 20:00 ` git gc --auto aquires *.lock files that make a subsequent git-fetch error out Jeff King
2017-07-12 20:30 ` Ævar Arnfjörð Bjarmason
2017-07-12 20:43 ` Jeff King
2013-01-26 22:40 ` [PATCH 2/2] fetch-pack: avoid repeatedly re-scanning pack directory Jeff King
2013-01-27 10:27 ` Jonathan Nieder
2013-01-27 20:09 ` Junio C Hamano
2013-01-27 23:20 ` Jonathan Nieder
2013-01-27 6:32 ` [PATCH 0/2] optimizing pack access on "read only" fetch repos Junio C Hamano
2013-01-29 8:06 ` Shawn Pearce
2013-01-29 8:29 ` Jeff King
2013-01-29 15:25 ` Martin Fick
2013-01-29 15:58 ` Junio C Hamano
2013-01-29 21:19 ` Jeff King
2013-01-29 22:26 ` Junio C Hamano
2013-01-31 16:47 ` Shawn Pearce
2013-02-01 9:14 ` Jeff King
2013-02-02 10:07 ` Shawn Pearce
2013-01-29 11:01 ` Duy Nguyen
-- strict thread matches above, loose matches on Subject: below --
2012-12-07 13:53 [PATCH 0/2] make repeated fetch faster on "read only" repos Jeff King
2012-12-07 13:58 ` [PATCH 1/2] fetch: run gc --auto after fetching Jeff King
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=20130126224038.GA20849@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.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 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).