Teach receive-pack how to keep pack files when unpacklooseobjects = 0.

Shawn Pearce <spearcespearce.org> writes:

> Since keeping a pushed pack or exploding it into loose
objects should
> be a local repository decision this teaches
receive-pack to decide
> if it should call unpack-objects or index-pack --stdin
--fix-thin
> based on the setting of receive.unpackLooseObjects.

One thing you can cheaply do is to tell the number of new
commits that is coming to receive-pack from send-pack when
it
sends the old..new pairs before it sends the packfile
payload.
It would be just a single internal rev-list call inside
send-pack, which is reasonably cheap.

If the receiving end knows how to process that new
information
(invent a "send-count" protocol extension and send
it just like
we already send "report-status" request), send one
extra packet
after flushing the list of old..new from send-pack to
receive-pack, to tell what the number of commits are, and
make a
matching change in receive-pack.

Then, instead of receive.unpackLooseObjects being a boolean,
you
can have it as a ceiling to decide if you have more than 100
commits you would keep it packed and otherwise you would
explode.  That would be very specific to the projects' size
(width of the tree) and style (huge commits vs lots of small
changes).


-
To unsubscribe from this list: send the line
"unsubscribe git" in
the body of a message to majordomovger.kernel.org
More majordomo info at  http://vge
r.kernel.org/majordomo-info.html