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