git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jakub Narebski <jnareb@gmail.com>
To: Abhishek Kumar <abhishekkumar8222@gmail.com>
Cc: git@vger.kernel.org, Derrick Stolee <stolee@gmail.com>,
	Christian Couder <christian.couder@gmail.com>
Subject: Re: [RFC][GSoC] Implement Generation Number v2
Date: Sun, 22 Mar 2020 21:05:26 +0100	[thread overview]
Message-ID: <86eetkrw8p.fsf@gmail.com> (raw)
In-Reply-To: <20200322093526.GA4718@Abhishek-Arch> (Abhishek Kumar's message of "Sun, 22 Mar 2020 15:05:26 +0530")

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.

> 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.

[...]
> ## 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

  reply	other threads:[~2020-03-22 20:05 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-22  9:35 [RFC][GSoC] Implement Generation Number v2 Abhishek Kumar
2020-03-22 20:05 ` Jakub Narebski [this message]
2020-03-23  4:25   ` Abhishek Kumar
2020-03-23  5:32     ` Junio C Hamano
2020-03-23 11:32       ` Abhishek Kumar
2020-03-23 13:43       ` Jakub Narebski
2020-03-23 15:54         ` Derrick Stolee
2020-03-24  9:24           ` Jakub Narebski
2020-03-23 16:04         ` Junio C Hamano
2020-03-24 15:44           ` Jakub Narebski
2020-03-24 21:13             ` Junio C Hamano
2020-03-26 10:15         ` [GSoC][Proposal v2] " Abhishek Kumar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86eetkrw8p.fsf@gmail.com \
    --to=jnareb@gmail.com \
    --cc=abhishekkumar8222@gmail.com \
    --cc=christian.couder@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=stolee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).