Use future date while making git commits

Question

Is there any easy way to postpone GitHub commits?

It would be also nice if these commits will go one after another in 1 hour.
Let\'s say if I have 5 commits, the

Answer 1

Note: if you need to postpone a commit in a very distant future, Git 2.13.x/Git 2.14 (Q3 2017) will accommodate your need.

Git's source code refers to timestamps as unsigned longs.
On 32-bit platforms, as well as on Windows, unsigned long is not large enough to capture dates that are "absurdly far in the future".

It is perfectly valid by the C standard, of course, for the long data type to refer to 32-bit integers. That is why the time_t data type exists: so that it can be 64-bit even if long is 32-bit.
Git's source code simply uses an incorrect data type for timestamps, is all.

See commit 28f4aee, commit 1e65a98, commit ffffdbad7 (26 Apr 2017), commit cb71f8b, commit 1aeb7e7 (21 Apr 2017), and commit efac8ac, commit a07fb05, commit e467dc1 (20 Apr 2017) by Johannes Schindelin (dscho).
See commit 3f78971 (08 May 2017) by Ramsay Jones (``).
^{(Merged by Junio C Hamano -- gitster -- in commit b15667b, 16 May 2017)}

use uintmax_t for timestamps

Previously, we used unsigned long for timestamps. This was only a good choice on Linux, where we know implicitly that unsigned long is what is used for time_t.

However, we want to use a different data type for timestamps for two reasons:

• there is nothing that says that unsigned long should be the same data type as time_t, and indeed, on 64-bit Windows for example, it is not:
  unsigned long is 32-bit but time_t is 64-bit.

• even on 32-bit Linux, where unsigned long (and thereby time_t) is 32-bit, we want to be able to encode timestamps in Git that are currently absurdly far in the future, even if the system library is not able to format those timestamps into date strings.

So let's just switch to the maximal integer type available, which should be at least 64-bit for all practical purposes these days. It certainly cannot be worse than unsigned long, so...

This is based on commit ffffdbad7 (part of this patch):

timestamp_t: a new data type for timestamps

Git's source code assumes that unsigned long is at least as precise as time_t. Which is incorrect, and causes a lot of problems, in particular where unsigned long is only 32-bit (notably on Windows, even in 64-bit versions).

So let's just use a more appropriate data type instead.
In preparation for this, we introduce the new timestamp_t data type.

As we will use a data type that is not necessarily identical to time_t, we need to be very careful to use time_t whenever we interact with the system functions, and timestamp_t everywhere else.

---

Note that, before Git 2.24 (Q4 2019), that new timestamp_t type was flawed.

See commit 2e09c01 (24 Sep 2019) by SZEDER Gábor (szeder).
Helped-by: Johannes Sixt (j6t).
^{(Merged by Junio C Hamano -- gitster -- in commit 0b4fae5, 09 Oct 2019)}

name-rev: avoid cutoff timestamp underflow

When 'git name-rev' is invoked with commit-ish parameters, it tries to save some work, and doesn't visit commits older than the committer date of the oldest given commit minus a one day worth of slop.
Since our 'timestamp_t' is an unsigned type, this leads to a timestamp underflow when the committer date of the oldest given commit is within a day of the UNIX epoch.
As a result the cutoff timestamp ends up far-far in the future, and 'git name-rev' doesn't visit any commits, and names each given commit as 'undefined'.

Check whether subtracting the slop from the oldest committer date would lead to an underflow, and use no cutoff in that case.
We don't have a TIME_MIN constant, ffffdbad7 (timestamp_t: a new data type for timestamps, 2017-04-26, Git v2.14.0-rc0) didn't add one, so do it now.

Note that the type of the cutoff timestamp variable used to be signed before 5589e87 (name-rev: change a "long" variable to timestamp_t, 2017-05-20, Git v2.14.0-rc0).
The behavior was still the same even back then, but the underflow didn't happen when substracting the slop from the oldest committer date, but when comparing the signed cutoff timestamp with unsigned committer dates in name_rev().
IOW, this underflow bug is as old as 'git name-rev' itself.