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

["Jakub Narębski" <jnareb@gmail.com>]

On Tue, 15 Sep 2020 at 23:14, Junio C Hamano <gitster@pobox.com> wrote:
> jnareb@gmail.com (Jakub Narębski) writes:
>
> > Those are patches that are part of GSoC project of Shourya Shukla:
> > 'Convert submodule to builtin'.
> > ...
> > Those are patches that are part of GSoC project of Hariom Verma:
> > 'Unify ref-filter formats with other --pretty formats'
>
> Yes and yes.  What is your intention for highlighting that these two
> are GSoC originated projects, by the way?

It was to compare the final status (merged vs not merged) of all Git's
GSoC 2020 projects... in a bit clumsy way, I admit.

[...]
> > 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
> > therefore we need some way to handle overflow if we choose this option.
> > And of course we should test that overflow handling works correctly.
>
> My gut feeling is that overflow handling needs to be there whether the
> field is 32-bit or 64-bit.

Not if the size on-disk is the same as the size in memory:
timestamp_t is usually 64 bit (and even unsigned 64 bit epoch
would be enough - its range is over twenty times the present
age of the universe per direction).

Best,
-- 
Jakub Narębski