Re: [RFC][GSoC] Implement Generation Number v2

From: Jakub Narebski <jnareb@gmail.com>
Date: Mar 22, 2020, 20:05 UTC
Message-ID: <86eetkrw8p.fsf@gmail.com>
In-Reply-To: <20200322093526.GA4718@Abhishek-Arch>

A few comments.

Abhishek Kumar <abhishekkumar8222@gmail.com> writes:

Show 8 quoted lines

> Hello everyone,
>
> Following the discussions between Jakub and Stolee [16], it was decided that
> implementing "Corrected Commit Date With Strictly Monotonic Offset" [17] was
> more appropriate for a GSoC project.
>
> I would like to work on it. The proposal could still use some work but I
> thought it would be best to get early feedback.

Thank you for your interest in this idea.

[...]

> ### Corrected Commit Date With Strictly Monotonic Offset
>
> Jakub later proposed a modification to corrected commit date, _Corrected Commit
> Date with Strictly Monotonic Offset_ defined as follows [7]:

I don't remember who originally proposed this idea, but it was not me. I have only given it the name you use.

Show 20 quoted lines

> For a commit C, let its _offset commit date_ (denoted by odate(C))
> be a commit date plus some offset, i.e. odate(C) = date(C) + offset(C),
> such that:
>
> 1. Offset commit date is greater than the maximum of the commit date of
>    C and the offset commit dates of its parents.
>
>     If odate(A) < odate(B), then A cannot reach B.
>
> 2. The offset of a commit is one more than the maximum offset of a parent, or
>    more.
>
>     If offset(A) < offset(B), then A cannot reach B.
>
> Since the offset are strictly greater than the offset of a parent, the old
> clients give correct values for the odate as well. `git commit-graph verify`
> would fail since the offsets are not generation numbers in all cases.
>
> This is an acceptable trade off because users can re-write the commit graph
> after verify fails.

One thing to solve is find and implement a way to distinguish between commit-graph with generation number v1 (legacy), and commit-graph with generation number v2.

Unfortunately for the time being we cannot use commit-graph format version; the idea that was proposed on the mailing list (when we found about the bug in handling commit-graph versioning, during incremental commit-graph implementation), was to create and use metadata chunk or versioning chunk (the final version of incremental format do not use this mechanism). This could be used by gen2 compatibile Git to distinguish between situation where old commit-graph file to be updated uses generation number v1, and when it uses v2.

If you have a better idea, please say so.

[...]

Show 12 quoted lines

> ## Contributions
>
> [Microproject] Consolidate test_cmp_graph logic
> -----
> Log graph comparison logic is duplicated many times. This patch consolidates
> comparison and sanitation logic in lib-log-graph.
>
> Status: Merged
>
> Patch: https://lore.kernel.org/git/20200216134750.18947-1-abhishekkumar8222@gmail.com/
>
> Commit: https://github.com/git/git/commit/46703057c1a0f85e24c0144b38c226c6a9ccb737

Nice, this is related work.

Best,

-- 
Jakub Narębski