On Sun, Mar 22, 2020 at 09:05:26PM +0100, Jakub Narebski wrote: > A few comments. > > Abhishek Kumar <abhishekkumar8222@xxxxxxxxx> 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. > > 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@xxxxxx/ > [...] > > ## 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@xxxxxxxxx/ > > > > Commit: https://github.com/git/git/commit/46703057c1a0f85e24c0144b38c226c6a9ccb737 > > Nice, this is related work. > > Best, > -- > Jakub Narębski Regards Abhishek
