Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > On Wed, Aug 16, 2017 at 11:05 PM, Junio C Hamano <gitster@xxxxxxxxx> 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.
