From: "Jakub Narębski" <email@example.com> To: Junio C Hamano <firstname.lastname@example.org> Cc: git <email@example.com>, Abhishek Kumar <firstname.lastname@example.org>, Derrick Stolee <email@example.com>, Taylor Blau <firstname.lastname@example.org> Subject: Re: What's cooking in git.git (Sep 2020, #03; Wed, 9) Date: Wed, 16 Sep 2020 00:02:34 +0200 [thread overview] Message-ID: <CANQwDwdgjV8ZTHKdUjEn5TKTXvTcODTXnbLEinWSQDYpZzfAvA@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Tue, 15 Sep 2020 at 23:45, Junio C Hamano <firstname.lastname@example.org> wrote: > > Jakub Narębski <email@example.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
prev parent reply other threads:[~2020-09-15 22:04 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-09 22:32 Junio C Hamano 2020-09-09 23:07 ` Eric Sunshine 2020-09-10 4:52 ` Junio C Hamano 2020-09-15 22:48 ` Eric Sunshine 2020-09-15 22:54 ` Junio C Hamano 2020-09-15 19:05 ` Jakub Narębski 2020-09-15 19:32 ` Taylor Blau 2020-09-15 21:14 ` Junio C Hamano 2020-09-15 21:25 ` Jakub Narębski 2020-09-15 21:45 ` Junio C Hamano 2020-09-15 21:48 ` Taylor Blau 2020-09-15 22:32 ` Junio C Hamano 2020-09-15 22:02 ` Jakub Narębski [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CANQwDwdgjV8ZTHKdUjEn5TKTXvTcODTXnbLEinWSQDYpZzfAvA@mail.gmail.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: What'\''s cooking in git.git (Sep 2020, #03; Wed, 9)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).