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. Two comments. * 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.
