Re: git filter-branch should run git gc --auto

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Jan 22, 2008, at 9:52 PM, Junio C Hamano wrote:

Junio C Hamano <gitster@xxxxxxxxx> writes:

Kevin Ballard <kevin@xxxxxx> writes:

Am I missing something, or does git-filter-branch really not do any
garbage collection? I tried reading the source, but complex bash
scripts are almost as bad as perl in terms of readability.

Theoretically yes, and it largely depends on what you do, but
filter-branch goes over the objects that already exists in your
repository, and hopefully you won't be rewriting majority of
them.

So the impact of not repacking is probably much less painful in
practice.

But again as I said, it largely depends on what you do in your
filter.  If you are upcasing (or convert to NFD ;-)) the
contents of all of your blob objects, you would certainly want
to repack every once in a while.

Something like this, perhaps?

git-filter-branch.sh |    6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ebf05ca..8e44001 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -299,6 +299,12 @@ while read commit parents; do
			die "msg filter failed: $filter_msg"
	sh -c "$filter_commit" "git commit-tree" \
		$(git write-tree) $parentstr < ../message > ../map/$commit
+
+	if test $(( $i % 512 )) = 0
+	then
+		git gc --auto
+	fi
+
done <../revs

# In case of a subdirectory filter, it is possible that a specified head



Offhand that looks good, but we'd probably want to unilaterally do another git-gc when we're done.

diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index ebf05ca..32274a6 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -299,8 +299,16 @@ while read commit parents; do
 			die "msg filter failed: $filter_msg"
 	sh -c "$filter_commit" "git commit-tree" \
 		$(git write-tree) $parentstr < ../message > ../map/$commit
+
+	if test $(( $i % 512 )) = 0
+	then
+		git gc --auto
+	fi
+
 done <../revs

+git gc --auto
+
# In case of a subdirectory filter, it is possible that a specified head
 # is not in the set of rewritten commits, because it was pruned by the
# revision walker. Fix it by mapping these heads to the next rewritten


--
Kevin Ballard
http://kevin.sb.org
kevin@xxxxxx
http://www.tildesoft.com


<<attachment: smime.p7s>>


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux