Check whether we have a large set of unpacked objects and repack after the fetch, but don't for the user to wait for us. --- There's been some discussion about repacking proactively without preventing further work. But as Linus said, repacking on an active repo is _safe_, so repack in the background. If we like this approach, we should at least respect a git-repo-config entry saying core.noautorepack for users who don't want it. I don't really know if there is any convention for us to check if we are in a resource-constrained situation (aka laptops on battery). If there is, we should respect that as well. I suspect anacron and others do this already but I can't find any references. We can potentially do it on commit, merge and push as well. --- git-fetch.sh | 6 ++++++ 1 files changed, 6 insertions(+), 0 deletions(-) 5498d015eb1062928a504af3c6b3cb9b776088e8 diff --git a/git-fetch.sh b/git-fetch.sh index 69bd810..4d64cdb 100755 --- a/git-fetch.sh +++ b/git-fetch.sh @@ -424,3 +424,9 @@ case ",$update_head_ok,$orig_head," in fi ;; esac + +if test $(git rev-list --unpacked --all | wc -l) -gt 1000 +then + echo "Repacking in the background" + nice git repack -a -d -q & +fi -- 1.3.2.g82000 - : send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html