From: Shawn O. Pearce Date: Thu, 06 Sep 2007 02:56:40 GMT Subject: Re: People unaware of the importance of "git gc"? Message-ID: <20070906025640.GL18160@spearce.org> In-Reply-To: <46DF6AA8.60804@midwinter.com> Steven Grimm wrote: > Shawn O. Pearce wrote: > >But this suffers from the same fate if the user sets gc.auto too > >small and doesn't realize that the reason Git is always repacking > >is because over the last 6 months they have been unlucky enough to > >stage the magic number of unreachable blobs into the 17 directory > >and they have *never* run `git gc --prune` because the auto thing > >is working just fine for them and they don't realize they need to > >prune every once in a blue moon. > > Check the modification times on those files and don't count ones that > are older than the last git-gc run, maybe? That'd take care of the problem. Eh, that could mean a bunch of stat calls that it would be nice to avoid. The counter Junio (and git-gui) implements just does a readdir(). Reasonably cheap. Maybe just save a ".git/gc_last_auto" with the last object count of .git/objects/17, after repacking. If the count is over the gc.auto limit *and* is still over the limit after subtracting the ".git/gc_last_auto" value then consider that auto is required. This way the file is only consulted if we are really thinking about running a repack, and its only written to if we actually do the repack. So we only take the extra penalty if we are going to be taking a *really* big extra penalty by repacking. -- Shawn.