Re: [PATCH] Reduce zlib deflate code duplication

From: Shawn Pearce <spearce@spearce.org>
Date: Aug 27, 2010, 01:56 UTC
Message-ID: <AANLkTikxxxxZwty156XG13QsOoimzYzuxSuTcf5KonTE@mail.gmail.com>
In-Reply-To: <1282856164-5126-1-git-send-email-pclouds@gmail.com>

2010/8/26 Nguyễn Thái Ngọc Duy <pclouds@gmail.com>:

Show 13 quoted lines

> Most of deflation code is simply "given this buffer, just deflate
> it". Make a common routine and reuse it instead.
>
> Exceptions include index-pack, http-push, fast-import,
> write_sha1_file, which either make multiple zlib streams, or compress
> and calculate sha1/checksum in parallel.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
>  There is possibly a regression here. remote-curl.c/post_rpc()
>  specifies more compression options, although I doubt it affects
>  performance. It also reveals places where deflation is expected
>  to be always successful.

It is a regression.

The compression options in remote-curl.c are to setup a gzip style stream, because that is what the servers expect. Your new common routine is using the bare deflation stream, which isn't the same header/footer formatting, and thus servers will choke with your change and smart HTTP payloads that are compressed by the client.

So yea, you can't get rid of all of those options for the remote-curl init. You'll need to still let remote-curl setup its options itself, and then pass you the zlib structure to deflate on.

-- 
Shawn.