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

From: Jakub Narębski <jnareb@gmail.com>
Date: Sep 15, 2020, 22:02 UTC
Message-ID: <CANQwDwdgjV8ZTHKdUjEn5TKTXvTcODTXnbLEinWSQDYpZzfAvA@mail.gmail.com>
In-Reply-To: <xmqqzh5qyar4.fsf@gitster.c.googlers.com>

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

Show 18 quoted lines

>
> Jakub Narębski <jnareb@gmail.com> writes:
>
>
> >> 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).
>
> Yes, and "corrected commit dates" is about accommodating commits
> with absurd out-of-sync timestamp mixed in a history with commits
> with correct timestamp, right?  What happens if the absurd timestamp
> is near the limit of the range?  You do not have to live through the
> end of the universe---you only have to create a commit object that
> records such a timestamp, no?

Well, as Git stores dates using timestamp_t type, it wouldn't be able to handle such commit dates anyway. Also, commit-graph format has only 34 bits reserved for storing commit dates anyway (32 + 2 bits, with 30 bits of the other byte used for topological levels aka generation number v1).

As parse_timestamp is strtoumax, having textual representation of timestamp not fit in 64 bits results in a range error (errno, which we do not check, is set to ERANGE) and UINTMAX_MAX is returned.

Best,

-- 
Jakub Narębski