Jakub Narebski <jna...@gmail.com> writes:
> Derrick Stolee <sto...@gmail.com> writes:
>> On 5/20/2019 7:02 AM, Jakub Narebski wrote:
>>>
>>> Are there any blockers that prevent the switch to this
>>> "generation number v2"?
>>>
>>> - Is it a problem with insufficient data to choose the correct numbering
>>> as "generation number v2' (there can be only one)?
>>> - Is it a problem with selected "generation number v2" being
>>> incompatibile with gen v2, and Git failing when new version of
>>> commit-graph is used instead of softly just not using commit-graph?
>>> - Or is it something else?
[...]
>> 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)
> offset(C) = corrected_date(C) - committer_date(C)
> gen_v2(C) = max(offset(C), max_{P ∈ parents(C)}(gen_v2(P)) + 1)
Do you remember who first came up with this idea for backward
compatibile corrected commit date offsets (monotonically offset
corrected date)?
> Do you have benchmark for this "monotonically offset corrected commit
> date" generation number in
> https://github.com/derrickstolee/git/commits/reach-perf
> and https://github.com/derrickstolee/gen-test ?
I guess this will have to wait...
Best,
--
Jakub Narębski
