@matheusbsbs / matheus-bagliano / commits / 131b8fcbfb

fetch: run gc --auto after fetching

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> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Jeff King committed Jan 26, 2013 at 17:40 UTC 131b8fcbfbea0acee8d78a8f9b2b3fee4285aee5

1 file changed +5

builtin/fetch.c

@@ -960,6 +960,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)

960 struct string_list list = STRING_LIST_INIT_NODUP;

961 struct remote *remote;

962 int result = 0;

963 + static const char *argv_gc_auto[] = {

964 + "gc", "--auto", NULL,

965 + };

966

967 packet_trace_identity("fetch");

968

@@ -1027,5 +1030,7 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)

1030 list.strdup_strings = 1;

1031 string_list_clear(&list, 0);

1032

1033 + run_command_v_opt(argv_gc_auto, RUN_GIT_CMD);

1034 +

1035 return result;

1036 }