On Tue, Jul 28, 2020 at 10:54:58AM -0400, Taylor Blau wrote: > 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! > > [...] > > 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
