On 5/20/2019 7:27 PM, Jakub Narebski wrote:
> Jakub Narebski <jnareb@xxxxxxxxx> writes:
>> Derrick Stolee <stolee@xxxxxxxxx> writes:
>>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>>>
>>>> Are there any blockers that prevent the switch to this
>>>> "generation number v2"?
> [...]
>
>>> Using the generation number column for the corrected
>>> commit-date offsets (assuming we also guarantee the offset is strictly
>>> increasing from parent to child), these new values will be backwards-
>>> compatible _except_ for 'git commit-graph verify'.
>>
>> O.K., so the "generation number v2 (legacy)" would be incremental and
>> backward-compatibile in use (though not in generation and validation).
>>
>> Do I understand it correctly how it is calculated:
>>
>> corrected_date(C) = max(committer_date(C),
>> max_{P ∈ parents(C)}(corrected_date(P)) + 1)
>
> This should probably read
>
> offset_date(P) = committer_date(P) + gen_v2(P)
> corrected_date(C) = max(committer_date(C),
> max_{P ∈ parents(C)}(offset_date(P)) + 1)
The final definition needs two conditions on the offset of a commit C for
every parent P:
1. committer_date(C) + offset(C) > committer_date(P) + offset(P)
2. offset(C) > offset(P)
Condition (1) will give us the performance benefits related to the
committer-date heuristic. Condition (2) will give us backwards-compatibility
with generation numbers.
Thanks,
-Stolee
