Re: reftable [v7]: new ref storage format

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 17, 2017, 18:22 UTC
Message-ID: <xmqqefsagikx.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAMy9T_GuU68mQTAvmPkaa6jPiNnoDAKCqA8y76rf3UrmMeyfTA@mail.gmail.com>

Michael Haggerty <mhagger@alum.mit.edu> writes:

Show 20 quoted lines

> On Wed, Aug 16, 2017 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I found it a slightly odd that we do not insist that update_indices
>> that appear in a single reftable file are consecutive, yet we
>> require that min_update_index of a reftable file must be one greater
>> than the max_update_index of a previous one.  That is not a new
>> issue in v7, though.
>
> I think of `update_index` like a pseudo-time, and the
> `min_update_index` and `max_update_index` to be stating that "this
> reftable covers the time interval specified". So it's reasonable to
> say that the reftable files, together, should cover all time.
>
> But it might be that there are values of `update_index` for which no
> events survived within a reftable file that covers that time interval.
> This can happen if reference update records have been compacted away
> because later reference updates overwrote their effects, and either
>
> * reflogs were turned off for those updates, or
> * the corresponding reflogs have been compacted into a separate file, or
> * the corresponding reflog entries for those updates have been expired.

Yeah, and I think it is reasonable that the specification does not dictate that indices within a single reftable must be consecutive.

And if update_indices within a single reftable are allowed to be sparse, e.g. recording three transactions with indices 1 3 and 5, it is not immediately obvious to me why the transactions that are recorded in the next reftable cannot be with indices 7 8 and 10, leaving a gap between the max in the first table (i.e. 5) and the min in the second table (i.e. 7). That is what I found slightly odd.