git/list[1] front-page[2] threads[3] people[4] search[5] about
 

[PATCH 1/2] fetch: run gc --auto after fetching

From
Jeff King <peff@peff.net>
Date
Jan 26, 2013, 22:40 UTC
Message-ID
<20130126224038.GA20849@sigill.intra.peff.net>
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
Previous: Jeff KingNext: Jonathan Nieder
Message 2 of 21 in “optimizing pack access on "read only" fetch repos”
  1. 0/2 optimizing pack access on "read only" fetch reposJeff King, Jan 26, 2013
  2. 1/2 fetch: run gc --auto after fetchingJeff King, Jan 26, 2013
  3. Jonathan NiederJan 27, 2013
  4. 2/2 fetch-pack: avoid repeatedly re-scanning pack directoryJeff King, Jan 26, 2013
  5. Jonathan NiederJan 27, 2013
  6. Junio C HamanoJan 27, 2013
  7. Jonathan NiederJan 27, 2013
  8. Junio C HamanoJan 27, 2013
  9. Shawn PearceJan 29, 2013
  10. Jeff KingJan 29, 2013
  11. Martin FickJan 29, 2013
  12. Junio C HamanoJan 29, 2013
  13. Jeff KingJan 29, 2013
  14. Junio C HamanoJan 29, 2013
  15. Shawn PearceJan 31, 2013
  16. Jeff KingFeb 1, 2013
  17. Shawn PearceFeb 2, 2013
  18. Duy NguyenJan 29, 2013
  19. Jeff KingJul 12, 2017
  20. Ævar Arnfjörð BjarmasonJul 12, 2017
  21. Jeff KingJul 12, 2017

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.