From efe4abd14c75834d30e3e521b3597eb07ea9271b Mon Sep 17 00:00:00 2001
From: Jim Meyering <jim@meyering.net>
Date: Wed, 15 Nov 2006 21:15:44 +0100
Subject: Run "git repack -a -d" once more at end, if there's 1MB or more of
 not-packed data.

Although I converted upstream coreutils to git last month, I just
reconverted coreutils once again, as a test, and ended up with a
git repository of about 130MB (contrast with my packed git repo of
size 52MB).  That was because there were a lot of commits (but < 1024)
after the final automatic "git-repack -a -d".

Running a final
  git-repack -a -d && git-prune-packed
cut the final repository size down to the expected size.

So this looks like an easy way to improve git-cvsimport.
Just run "git repack ..." at the end if there's more than
some reasonable amount of not-packed data.

My choice of 1MB is a little arbitrarily.  I wouldn't mind missing
the minimal repo size by 1MB.  At the other end of the spectrum,
it's probably not worthwhile to pack everything when the total
repository size is less than 1MB.

Here's the patch:

Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>

diff --git a/git-cvsimport.perl b/git-cvsimport.perl
index 14e2c61..b54a948 100755
--- a/git-cvsimport.perl
+++ b/git-cvsimport.perl
@@ -876,6 +876,16 @@ while(<CVS>) {
 }
 commit() if $branch and $state != 11;
 
+# The heuristic of repacking every 1024 commits can leave a
+# lot of unpacked data.  If there is more than 1MB worth of
+# not-packed objects, repack once more.
+my $line = `git-count-objects`;
+if ($line =~ /^(\d+) objects, (\d+) kilobytes$/) {
+  my ($n_objects, $kb) = ($1, $2);
+  1024 < $kb
+    and system("git repack -a -d");
+}
+
 foreach my $git_index (values %index) {
     if ($git_index ne '.git/index') {
 	unlink($git_index);
-- 
cgit v0.10.2-6-g49f6