Re: reftable [v6]: new ref storage format
- Date: Tue, 08 Aug 2017 12:25:16 -0700
- From: Junio C Hamano <gitster@xxxxxxxxx>
- Subject: Re: reftable [v6]: new ref storage format
Shawn Pearce <spearce@xxxxxxxxxxx> writes:
> For `log_type = 0x4..0x7` the `log_chained` section is used instead to
> compress information that already appeared in a prior log record. The
> `log_chained` always includes `old_id` for this record, as `new_id` is
> implied by the prior (by file order, more recent) record's `old_id`.
> The `not_same_committer` block appears if `log_type & 0x1` is true,
> `not_same_message` block appears if `log_type & 0x2` is true. When
> one of these blocks is missing, its values are implied by the prior
> (more recent) log record.
* not-same-committer would be what I would use when I switch
timezones, even if I stay to be me, right? I am just wondering
if it is clear to everybody that "committer" in that phrase is a
short-hand for "committer information other than the timestamp".
* Should the set of entries that are allowed to use of "chained"
log be related to the set of entries that appear in the restart
table in any way? For a reader that scans starting at a restart
point, it would be very cumbersome if the entry were chained from
the previous entry, as it would force it to backtrack entries to
find the first non-chained log entry. A simple "log_chained must
not be used for an entry that appear in the restart table" rule
would solve that, but I didn't see it in the document.