list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
From: "Jakub Narębski" <>
To: Junio C Hamano <>
Cc: git <>,
	Abhishek Kumar <>,
	Derrick Stolee <>, Taylor Blau <>
Subject: Re: What's cooking in git.git (Sep 2020, #03; Wed, 9)
Date: Wed, 16 Sep 2020 00:02:34 +0200
Message-ID: <> (raw)
In-Reply-To: <>

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

Jakub Narębski

      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:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ \
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
 note: .onion URLs require Tor:

code repositories for the project(s) associated with this inbox:

AGPL code for this site: git clone