Re: reftable [v7]: new ref storage format

Michael Haggerty [off-list ref] writes:

On Wed, Aug 16, 2017 at 11:05 PM, Junio C Hamano [off-list ref] wrote:

quoted

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.