On Tue, 15 Sep 2020 at 23:45, Junio C Hamano <gitster@xxxxxxxxx> wrote: > > Jakub Narębski <jnareb@xxxxxxxxx> 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
