[RFC] git-fetch - repack in the background after fetching

From: Martin Langhoff <martin@catalyst.net.nz>
Date: Jun 24, 2006, 11:30 UTC
Message-ID: <11511486003924-git-send-email-martin@catalyst.net.nz>

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. Conditional on core.autorepack =! no.

Having ' handle concurrent pruning of packed objects' (637cdd9d1d997fca34a1fc668fed1311e30fe95f) from Jeff King it should be safe to repack and prune in the background.

Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>

---

This is a follow up to a similar patch earlier http://www.gelato.unsw.edu.au/archives/git/0605/21401.html -- is there interest in making GIT more friendly to users who don't know or care about packing and repacking their repos?

I loathe to do this conditionally only on the count of unpacked objects. If there's a quick'n'dirty way of asking portably whether the machine is busy or otherwise resource-constrained (ie: on battery) it should use it to avoid running repack at inconvenient times.

---
 git-fetch.sh |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/git-fetch.sh b/git-fetch.sh
index 48818f8..7211318 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -427,3 +427,12 @@ case ",$update_head_ok,$orig_head," in
 	fi
 	;;
 esac
+
+if test "$(git-repo-config --get core.autorepack)" != 'no'
+then
+	if test $(git rev-list --unpacked --all | wc -l) -gt 1000
+	then
+		echo "Repacking in the background"
+		nice git repack -a -d -q &
+	fi
+fi

-- 
1.4.1.rc1.g59c8