Nicolas Pitre [off-list ref] writes:
quoted
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.
Bzzt, I am releaved to see you are sometimes wrong ;-)
They are reachable from the index and are not subject to
pruning.
quoted
git fetch
I think that would be a much better idea to simply decrease the
fetch.unpackLimit default value.
One thing that I find lacking in that auto patch is actually
that we should sometimes consolidate multiple small packs into a
single larger one. Any behaviour change to encourage creation
of many tiny packs should be avoided until it materializes.
Probably we should introduce a built-in minimum value for a
positive gc.auto, somewhere around 1000 or so, for this reason.
On Wed, 5 Sep 2007, Junio C Hamano wrote:
Nicolas Pitre [off-list ref] writes:
quoted
quoted
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.
Bzzt, I am releaved to see you are sometimes wrong ;-)
They are reachable from the index and are not subject to
pruning.
The index? What's that? ;-)
quoted
quoted
git fetch
I think that would be a much better idea to simply decrease the
fetch.unpackLimit default value.
One thing that I find lacking in that auto patch is actually
that we should sometimes consolidate multiple small packs into a
single larger one. Any behaviour change to encourage creation
of many tiny packs should be avoided until it materializes.
Probably we should introduce a built-in minimum value for a
positive gc.auto, somewhere around 1000 or so, for this reason.
Why not just let the default value take care of it? If someone really
wants to set gc.auto to 50, why prevent it?
The more I think of it, the less I like automatic repack. There is
always a bad case for it somewhere.
Nicolas