Re: [PATCH 2/8] pack-objects: produce a stable pack when --skip is given

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 8, 2016, 05:23 UTC
Message-ID: <CACsJy8CyFnUGdBQ4XQ5jvfc7GY08jQkB-z70bDSdSNAPigYDvQ@mail.gmail.com>
In-Reply-To: <CAPc5daXmci5TTc0zqKe+izbrQ5XmHd75V=ZKjoWN8hMPTJPSTQ@mail.gmail.com>

On Sat, Feb 6, 2016 at 7:48 AM, Junio C Hamano <gitster@pobox.com> wrote:

Show 11 quoted lines

>> You noticed that tying the behavior only happens when the user asks
>> for it, right? I don't expect people to do resumable fetch/clone by
>> default. There are tradeoffs to make and they decide it, we offer
>> options. So, it does not really tie our hands in the normal case.
>
> You misread me. I do not want to see us having to add
> "disable_this_feature = 1" next to that "delta_search_thread = 1"
> in this block, and then supporting code to actually disable that
> feature, only to support this block. You are declaring that "to
> support this mode, we must always have a way to produce a
> byte-for-byte identical output and keep supporting it forever".

My last defense is, this is an extension, not part of the core protocol. If the burden becomes real we can always remove it. Modem-quality connection users may yell a bit, but the majority of broadband users won't notice a thing. But I understand if the answer is still 'no'.

I find it unlikely that this cause much maintenance burden though, the packing algorithm has not changed for a very long time (most related change is pack bitmaps, which technically happen before pack-objects). The next big change (at least in public) may be pack v4. We haven't found a good algorithm for pack-objects on v4 yet, so there's a chance of problems there.

-- 
Duy