From: "Jakub Narębski" <firstname.lastname@example.org> To: Junio C Hamano <email@example.com> Cc: git <firstname.lastname@example.org>, Abhishek Kumar <email@example.com>, Derrick Stolee <firstname.lastname@example.org>, Taylor Blau <email@example.com> Subject: Re: What's cooking in git.git (Sep 2020, #03; Wed, 9) Date: Tue, 15 Sep 2020 23:25:16 +0200 [thread overview] Message-ID: <CANQwDwc3-n4X16F1Xuf-y-yLeXoGRTeT5c=kVVFXH1E6P=ZEqA@mail.gmail.com> (raw) In-Reply-To: <firstname.lastname@example.org> On Tue, 15 Sep 2020 at 23:14, Junio C Hamano <email@example.com> wrote: > firstname.lastname@example.org (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
next prev parent reply other threads:[~2020-09-15 21:27 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 [this message] 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
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='CANQwDwc3-n4X16F1Xuf-y-yLeXoGRTeT5c=kVVFXH1E6P=ZEqA@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --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).