Re: Revision walking, commit dates, slop

From: Derrick Stolee <stolee@gmail.com>
Date: May 21, 2019, 01:20 UTC
Message-ID: <88662e18-db51-cb48-3307-0ea2a91c4ebe@gmail.com>
In-Reply-To: <864l5opuz1.fsf@gmail.com>

On 5/20/2019 7:27 PM, Jakub Narebski wrote:

Show 26 quoted lines

> Jakub Narebski <jnareb@gmail.com> writes:
>> 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"?
> [...]
> 
>>>                      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