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-p
On Tue, Sep 3, 2013 at 1:49 PM, Jeff King 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 the pack
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
> unconditio
On Sun, Sep 1, 2013 at 11:05 PM, Nguyễn Thái Ngọc Duy 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 index-pack
> un
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
unconditionally, then turn objects loose and remove the pack at the
end. unpack-objects i
5 matches
Mail list logo
