Re: [PATCH 0/6] [GSoC] Implement Corrected Commit Date

From: Abhishek Kumar <abhishekkumar8222@gmail.com>
Date: Jul 30, 2020, 07:47 UTC
Message-ID: <20200730074701.GA10743@Abhishek-Arch>
In-Reply-To: <20200728145458.GA87373@syl.lan>

On Tue, Jul 28, 2020 at 10:54:58AM -0400, Taylor Blau wrote:

Show 9 quoted lines

> Hi Abhishek,
> 
> On Tue, Jul 28, 2020 at 09:13:45AM +0000, Abhishek Kumar via GitGitGadget wrote:
> > This patch series implements the corrected commit date offsets as generation
> > number v2, along with other pre-requisites.
> 
> Very exciting. I have been eagerly following your blog and asking
> Stolee about your progress, so I am excited to read these patches.
>

I am so glad to hear that!

Show 10 quoted lines

> 
> [...]
> 
> I'm sure that I'll learn more when I get to this point, but I would like
> to hear more about why you want to store the offset rather than the
> corrected commit date itself. It seems that the offset could be either
> positive or negative, so you'd only have the range of a signed integer
> (rather than storing 8 bytes of a time_t for the full breadth of
> possibilities).
>

Corrected commit dates are at least as big as the committer date, so the offset (i.e. corrected date - committer date) would never be negative.

We store offsets instead of corrected commit dates because:
- We save 4 bytes for each commit, which amounts to 7-8% of the size of
  commit graph file (of course, dependent on the other chunks used).
- We save some time while writing the commit-graph file too, around
  ~200ms for the Linux repo.

While the savings are modest, writing corrected dates does not offer any advantage that we could think of, at the time.

> I know also that Peff is working on negative timestamp support, so I
> would want to hear about what he thinks of this, too.

I have read up on Peff's work with negative timestamp support and it's pretty exciting.

> [...]

Thanks
- Abhishek