git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Revision walking, commit dates, slop

From
Derrick Stolee <stolee@gmail.com>
Date
Jun 25, 2019, 10:54 UTC
Message-ID
<55fad895-2c18-5a91-79b9-7b958fe280c6@gmail.com>
In-Reply-To
<86mui63xwr.fsf@gmail.com>
On 6/25/2019 3:51 AM, Jakub Narebski wrote:
Show 33 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"?
>>>>
>>>> - 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)?
I remember saying that the "corrected commit date" that I had suggested
was weak because it was not backwards-compatible with generation numbers
if you are only looking at the offsets. I don't remember who suggested
simply increasing the offset so they do become backwards-compatible.
 
Show 5 quoted lines
>> 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...

I have not had time to revisit this topic and re-run performance numbers, sorry.

-Stolee
Previous: Jakub NarebskiNext: Jakub Narebski
Message 21 of 23 in “Revision walking, commit dates, slop”
  1. Mike HommeyMay 18, 2019
  2. SZEDER GáborMay 18, 2019
  3. Mike HommeyMay 18, 2019
  4. Mike HommeyMay 18, 2019
  5. SZEDER GáborMay 18, 2019
  6. Jakub NarebskiMay 19, 2019
  7. Derrick StoleeMay 20, 2019
  8. Jakub NarebskiMay 20, 2019
  9. Derrick StoleeMay 20, 2019
  10. Jakub NarebskiMay 20, 2019
  11. Jakub NarebskiMay 20, 2019
  12. Derrick StoleeMay 21, 2019
  13. Jonathan NiederMay 21, 2019
  14. revision: use generation for A..B --topo-order queriesDerrick Stolee, May 21, 2019
  15. 2/2 revision: keep topo-walk free of unintersting commitsDerrick Stolee, May 21, 2019
  16. Mike HommeyMay 22, 2019
  17. Jakub NarebskiMay 22, 2019
  18. Derrick StoleeMay 22, 2019
  19. Jakub NarebskiMay 23, 2019
  20. Jakub NarebskiJun 25, 2019
  21. Derrick StoleeJun 25, 2019
  22. commit-graph: generation v5 (backward compatible date ceiling)Jakub Narebski, Sep 18, 2019
  23. Derrick StoleeSep 18, 2019

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.