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

From: Jakub Narębski <jnareb@gmail.com>
Date: Sep 15, 2020, 21:25 UTC
Message-ID: <CANQwDwc3-n4X16F1Xuf-y-yLeXoGRTeT5c=kVVFXH1E6P=ZEqA@mail.gmail.com>
In-Reply-To: <xmqqimcezqs5.fsf@gitster.c.googlers.com>

On Tue, 15 Sep 2020 at 23:14, Junio C Hamano <gitster@pobox.com> wrote:

Show 10 quoted lines

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

[...]

Show 9 quoted lines

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