On Wed, 22 Apr 2009, Brandon Casey wrote: > Nicolas Pitre wrote: > > On Wed, 22 Apr 2009, Brandon Casey wrote: > > >> I've often wondered whether a plain 'git gc' should adopt the behavior > >> of --auto with respect to the number of packs. If there were few packs, > >> then 'git gc' would do an incremental repack, rather than a 'repack -A -d -l'. > > > > Why so? Having fewer packs is always a good thing. Having only one > > pack is of course the optimal situation. The --auto version doesn't do > > it in the hope of being lightter and less noticeable by the user. > > The only reason for avoiding packing all packs into one would be speed in > this case also. I recall reading complaints or surprise about gc > repacking all packs into one, so I'm only trying to think about how to > match program behavior with user expectations. It's user's expectations that need adjusting then. Making a single pack is indeed the job of an explicit gc invocation. > gc does a lot already, and even Jeff wasn't sure what to expect from > 'git gc' with respect to packs. Possibly an acceptable trade off > between speed and optimal packing would be to adopt the --auto > behavior for deciding when to use '-A' with repack. And what would be the point of manually running 'git gc' then, given that 'git gc --auto' is already invoked automatically after most commit creating commands? I mean, if you consider explicit 'git gc' too long, then simply wait until you can spare the time, if at all. This is not like a non gc'd repository suddently becomes non functional. WRT trade offs, the current behavior is already a pretty good compromize between speed and optimal packing, the later implying -f to 'git repack' which is far far slower. Nicolas -- 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