Re: People unaware of the importance of "git gc"?

From: Nicolas Pitre <nico@cam.org>
Date: Sep 5, 2007, 20:35 UTC
Message-ID: <alpine.LFD.0.9999.0709051634190.21186@xanadu.home>
In-Reply-To: <7vr6lcj2zi.fsf@gitster.siamese.dyndns.org>

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

Show 9 quoted lines

> 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.

Show 6 quoted lines

> 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.

> 	git fetch

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

>         git merge
>         git rebase

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

Nicolas