Re: [RFC][GSoC] Implement Generation Number v2
- From
Abhishek Kumar <abhishekkumar8222@gmail.com>
- Date
- Mar 23, 2020, 04:25 UTC
- Message-ID
- <20200323042517.GA1258@Abhishek-Arch>
- In-Reply-To
- <86eetkrw8p.fsf@gmail.com>
On Sun, Mar 22, 2020 at 09:05:26PM +0100, Jakub Narebski wrote:
Show 24 quoted lines
> A few comments. > > Abhishek Kumar <abhishekkumar8222@gmail.com> writes: > > > 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. >
Thanks, noted. Will update it.
Show 36 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. >
We could also use a flag file. Here's how it works:
If the file `.git/info/generation-number-v2` exists, use gen2. Otherwise use gen1.
We can, of course generalize this to `<dir>/info/generation-number-v2` if needed.
1. It is independent of commit-graph format.
2. Switching between versions requires creating/deleting a file, which is simpler than reading commit-graph file and modifying (or removing) a metadata chunk.
Johannes used a similar flag file during the conversion of difftool [1].
[1]: https://lore.kernel.org/git/598dcfdbeef4e15d2d439053a0423589182e5f30.1479834051.git.johannes.schindelin@gmx.de/
Show 19 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
Regards Abhishek