From: "Jakub Narębski" <jnareb@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git <git@vger.kernel.org>,
Abhishek Kumar <abhishekkumar8222@gmail.com>,
Derrick Stolee <stolee@gmail.com>, Taylor Blau <me@ttaylorr.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: <xmqqimcezqs5.fsf@gitster.c.googlers.com>
On Tue, 15 Sep 2020 at 23:14, Junio C Hamano <gitster@pobox.com> wrote:
> 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.
[...]
> > 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 What's cooking in git.git (Sep 2020, #03; Wed, 9) 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
* 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' \
--to=jnareb@gmail.com \
--cc=abhishekkumar8222@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=me@ttaylorr.com \
--cc=stolee@gmail.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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 NNTP newsgroup(s).