On Wed, 5 Sep 2007, Junio C Hamano wrote:

quoted text
> Implement git gc --auto
> 
> This implements a new option "git gc --auto".  When gc.auto is
> set to a positive value, and the object database has accumulated
> roughly that many number of loose objects, this runs a
> lightweight version of "git gc".  The primary difference from
> the full "git gc" is that it does not pass "-a" option to "git
> repack", which means we do not try to repack _everything_, but
> only repack incrementally.  We still do "git prune-packed".  

A big part of the repack cost is the counting of objects. I don't know 
if --unpacked to git-pack-objects skips walking trees of a packed commit 
object.  If no then it probably should to gain a significant speed up, 
or maybe a separate option should be created to actually imply this 
loosened semantic.

quoted text
> This patch does not add invocation of the "auto repacking".  It
> is left to key Porcelain commands that could produce tons of
> loose objects to add a call to "git gc --auto" after they are
> done their work.  Obvious candidates are:
> 
> 	git add

Nope!  'git add' creates loose objects which are not yet reachable from 
anywhere.  They won't get repacked until a commit is made.

quoted text
> 	git fetch

I think that would be a much better idea to simply decrease the 
fetch.unpackLimit default value.

quoted text
>         git merge
>         git rebase        

and git commit.  Which resumes it to commit creating operation.


Nicolas
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html