On Wed, 15 Jun 2011, Geoff Russell wrote: > On Thu, Jun 9, 2011 at 2:39 AM, Jakub Narebski <jnareb@xxxxxxxxx> wrote: > > Peter Harris <git@xxxxxxxxxxxxxxxxxxx> writes: > > > On Tue, Jun 7, 2011 at 9:33 PM, Geoff Russell wrote: > > > > > > > > As of today, almost every time I do a git command, gc is getting > > > > invoked. > > > > > > > There are 96 pack files. > > > > > > That's why. See gc.autopacklimit in "git help config" -- by default, > > > git will gc if there are more than 50 pack files. > > > > Actually it looks like it is combination of this and packSizeLimit set > > to 30M. Git notices that it has too many packfiles, and tries to > > repack them, but packlimit forces Git to split it into small > > packfiles... and end up with more packfiles than limit anyway. > > Thanks to everybody. This is exactly what was happening and the problems > went away when I set the packSizeLimit higher ... 3000M Why did you set packSizeLimit at all? > > > > Perhaps git should notice that it has nonsensical combination of > > options... > > That would be nice. It should be reasonably easy to work out that the > packSizeLimit will guarantee too many pack files after the gc. > Disobeying a users wishes shouldn't be undertaken lightly, but sometimes > we stuff up :) Well, git can simply notice that each except perhaps on file has size greater or equal to gc.packSizeLimit, and then ignore gc.autopacklimit hint, because repacking would not reduce number of packs, and not lower it below gc.autopacklimit. If `git gc` is called interactively, we can warn user about this situation... -- Jakub Narebski Poland -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html