Re: Why repository grows after "git gc"? / Purpose of *.keep files?

Paolo Bonzini wrote (2008-05-13 07:08 +0200):

I think separate cutoffs should be in place for file size and number
of  objects.  Very tight packs probably require hours to repack as
efficiently.

[...]

Thinking about both use cases, the best would be to have options
(common  to git-clone, git-remote add, git-gc at least; and available
via config  keys too) like

  --keep-packs[=THRES1,THRES2,...]

Some thoughts from user interface's point of view. Two assumptions:

  - gc is daily or weekly operation
  - gc --aggressive is more like weekly or monthly operation.

In big repositories gc can feel pretty slow if there are not any .keep
packs and user runs the command daily. So I think there's a point in
having a .keep pack in repositories the size of linux-2.6 for example.
But at the same time I think it would be nice to have an easy UI-way to
repack with better disk space optimization.

This started as a crazy idea but maybe it's not so crazy so I'll
rephrase my previous suggestion. At final stage the command gc
--aggressive would add new .keep file which contains an identifier like

  This .keep file was added by "gc --aggressive" and
  will be automatically deleted at next run.

(Or something like that, you get the idea.)

At first gc --aggressive looks for .keep files with such identifier and
deletes them if found. Then it proceeds normally and finally adds new
.keep file with the same identifier.

This way the "daily" gc would operate very fast (as it leaves .keep
packs alone), and with gc --aggressive user could easily decide when to
create new landmark .keep packs (and also prune possible dangling
objects inside previous .keep packs). Normal user don't need to know the
details. Just run gc occasionally and maybe gc --aggressive when better
optimization is needed.

How does this sound?