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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Sep 1, 2013 at 11:05 PM, Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx> 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
> unconditionally, then turn objects loose and remove the pack at the
> end. unpack-objects is deprecated and may be removed in future.
>
> There are a few reasons for this:
>
>  - down to two code paths to maintain regarding pack reading
>    (sha1_file.c and index-pack.c). When .pack v4 comes, we don't need
>    to duplicate work in index-pack and unpack-objects.
>
>  - the number of objects should not be the only indicator for
>    unpacking. If there are a few large objects in the pack, the pack
>    should be kept anyway. Keeping the pack lets us examine the whole
>    pack later and make a better decision.
>
>  - 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 contains a small number of objects.
>
>  - unpack-objects does not support streaming large blobs. Granted
>    force_object_loose(), which is used by this patch, does not either.
>    But it'll be easier to do so because sha1_file.c interface supports
>    streaming.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@xxxxxxxxx>
--
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




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]