Re: reftable [v7]: new ref storage format

From: Michael Haggerty <mhagger@alum.mit.edu>
Date: Aug 17, 2017, 08:06 UTC
Message-ID: <CAMy9T_GuU68mQTAvmPkaa6jPiNnoDAKCqA8y76rf3UrmMeyfTA@mail.gmail.com>
In-Reply-To: <xmqq60dnjka0.fsf@gitster.mtv.corp.google.com>

On Wed, Aug 16, 2017 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:

Show 5 quoted lines

> 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.

Michael