Re: Revision walking, commit dates, slop

From: Jakub Narebski <jnareb@gmail.com>
Date: May 20, 2019, 23:27 UTC
Message-ID: <864l5opuz1.fsf@gmail.com>
In-Reply-To: <86ftp9p7i8.fsf@gmail.com>

Jakub Narebski <jnareb@gmail.com> writes:

Show 5 quoted lines

> Derrick Stolee <stolee@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"?

[...]

Show 12 quoted lines

>>                      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)

Show 6 quoted lines

>   offset(C) = corrected_date(C) - committer_date(C)
>   gen_v2(C) = max(offset(C), max_{P ∈ parents(C)}(gen_v2(P)) + 1) 
>
> 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 ?

-- Jakub Narębski