On Wed, Jun 19, 2019 at 04:46:30PM +0700, Nguyễn Thái Ngọc Duy wrote: > In multiple remotes mode, git-fetch is launched for n-1 remotes and the > last remote is handled by the current process. Each of these processes > will in turn run 'gc' at the end. > > This is not really a problem because even if multiple 'gc --auto' is run > at the same time we still handle it correctly. It does show multiple > "auto packing in the background" messages though. And we may waste some > resources when gc actually runs because we still do some stuff before > checking the lock and moving it to background. > > So let's try to avoid that. We should only need one 'gc' run after all > objects and references are added anyway. Add a new option --no-auto-gc > that will be used by those n-1 processes. 'gc --auto' will always run on > the main fetch process (*). Yeah, that makes sense. I was surprised that we needed a new command-line option here, but I guess the sub-fetch processes really have no idea that they're subservient to a multi-remote fetch (they do get "--append", but of course somebody could specify that independently). Another option would be to just pass "-c gc.auto=0" to the child processes to inhibit auto-gc. But maybe it makes sense to have a nicer interface (after all, somebody else could be doing the same "let's do a bunch of fetches in a row" without using the multi-fetch code). Though there I kind of wonder if this would apply to other scripted uses, too. E.g., if I'm doing a bunch of commits, I might want to inhibit auto-gc and then run it myself at the end. Should we support "GIT_AUTO_GC=0" in the environment (and a matching "git --no-auto-gc ..." option that could be used here)? > Documentation/fetch-options.txt | 4 ++++ > builtin/fetch.c | 17 +++++++++++------ > t/t5514-fetch-multiple.sh | 7 +++++-- > 3 files changed, 20 insertions(+), 8 deletions(-) My musings above aside, the patch looks correct to me. -Peff
