Shawn Pearce <spearce@xxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html