Re: [PATCH] send-pack: don't send a thin pack when the server doesn't support it

From: Duy Nguyen <pclouds@gmail.com>
Date: Oct 8, 2013, 11:29 UTC
Message-ID: <CACsJy8AHAbDuz3yhsjJfRQUGg1zzx6qqoAf=1oNhbX1xPVithg@mail.gmail.com>
In-Reply-To: <CACsJy8AQ-719sbUfJW98q_HYit7ePfB6oN3v7XTX6fvC7HnixA@mail.gmail.com>

On Tue, Oct 8, 2013 at 4:44 PM, Duy Nguyen <pclouds@gmail.com> wrote:

Show 16 quoted lines

> On Tue, Oct 8, 2013 at 3:44 PM, Carlos Martín Nieto <cmn@elego.de> wrote:
>> diff --git a/send-pack.c b/send-pack.c
>> index 7d172ef..7b88ac8 100644
>> --- a/send-pack.c
>> +++ b/send-pack.c
>> @@ -205,6 +205,8 @@ int send_pack(struct send_pack_args *args,
>>                 quiet_supported = 1;
>>         if (server_supports("agent"))
>>                 agent_supported = 1;
>> +       if (!server_supports("thin-pack"))
>> +               args->use_thin_pack = 0;
>
> Hmm.. I think this introduces a regression in C Git because
> receive-pack never advertises "thin-pack" and so "git push" from now
> on will never send thin packs. It's too late now to add thin-pack to
> receive-pack

Or maybe it's not that late. How about you go with your patch and add thin-pack capability to receive-pack too?

When new "git push" is used against old server, thin pack is disabled. But that's not a big deal (I hope). The difference is traffic increases a bit more, but cpu consumption on the server side is also a bit less. Pushes are usually small, unless you do initial push, which is complete anyway. So a bit more or less does not really matter in practice.

We could mitigate the regression a bit by checking agent string and enable thin-pack for those versions even if thin-pack is not advertises. That goes back to v1.7.12. We may do the same for some other popular git servers. And this hack is maintained like 3-4 years, enough time for new versions to be deployed, then removed.

Hmm?

-- 
Duy