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

quoted text
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Kevin Ballard <kevin@sb.org> 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@sb.org
http://www.tildesoft.com