Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

On Mon, Sep 02, 2013 at 10:05:07AM +0700, Nguyen Thai Ngoc Duy wrote: Current code peaks into the transfered pack's header, if the number of objects is under a limit, unpack-objects is called to handle the rest, otherwise index-pack is. This patch makes fetch-pack use index-pack

Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

On Tue, Sep 3, 2013 at 1:49 PM, Jeff King p...@peff.net wrote: - by going through index-pack first, then unpack, we pay extra cost for completing a thin pack into a full one. But compared to fetch's total time, it should not be noticeable because unpack-objects is only called when

Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

On Tue, Sep 03, 2013 at 06:56:23PM +0700, Nguyen Thai Ngoc Duy wrote: ...but the cost is paid by total pack size, not number of objects. So if I am pushing up a commit with a large uncompressible blob, I've effectively doubled my disk I/O. It would make more sense to me for index-pack to

Re: [PATCH] {fetch,receive}-pack: drop unpack-objects, delay loosing objects until the end

On Sun, Sep 1, 2013 at 11:05 PM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote: Current code peaks into the transfered pack's header, if the number of s/peaks/peeks/ objects is under a limit, unpack-objects is called to handle the rest, otherwise index-pack is. This patch makes fetch-pack use