Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)

[Taylor Blau <me@ttaylorr.com>]

Hi Jakub,

On Tue, Sep 15, 2020 at 09:05:18PM +0200, Jakub Narębski wrote:
> I'd like to point out that latest series of patches by Abhishek Kumar
> which are final part of 'Implement Generation Number v2' is at what I
> believe is next to final iteration:
>
>   "[PATCH v3 00/11] [GSoC] Implement Corrected Commit Date"
>   https://lore.kernel.org/git/pull.676.v3.git.1597509583.gitgitgadget@gmail.com/T/#u
>
> It is waiting for the decision on *how to implement storing* new
> generation number in the commit-graph file: should we store corrected
> commit date directly as 64 bit value, or should we store corrected
> commit date offset as 32 bit value with overflow handling?
>
> Switching from 64 bits to 32 bits halves the size of the GDAT
> (Generation DATa) chunk, but decreases the size of the commit-graph file
> by at most 7%.  For large repository, like MS Windows with 3M commits in
> 2019 it would mean decreasing the size of the commit-graph file by
> 11.8 MiB (if I calculated it correctly).
>
> Because corrected commit date offsets are not monotone, that is after
> value that doesn't fit in 32 bits (in parent) there can be one that does
> (in child).  It is extremely unlikely that in real repositories there
> would be that large corrections needed, but it can happen in theory, and
> therfore we need some way to handle overflow if we choose this option.
> And of course we should test that overflow handling works correctly.
>
> So there is tradeoff between complexity and commit-graph file size.

If you think that not being able to fit into 32 bits is unlikely, then I
don't think it makes sense to store those same values inside of 64 bits,
either.

Of course, that means implementing overflow detection, but that's a
small price to pay for shaving off extra data from the commit-graph
file.

> Best,
> --
> Jakub Narębski

Thanks,
Taylor