在进行 git 提交时使用未来日期

Question

有什么简单的方法可以推迟 GitHub 提交吗​​？

如果这些提交能在 1 小时内一个接一个地进行，那就太好了。
假设我有 5 个提交，第一个应该出现在上午 10 点，第二个出现在上午 11 点，第三个出现在下午 12 点，依此类推。

Answer 1

您可以使用 commit --date 参数：

git commit -m "message" --date "Tue Apr 28 23:00:00 2015 +0300"

更新： 还有一个非常酷的脚本来改变旧的提交日期（你需要 Perl 来运行它）： https://raw.githubusercontent.com/gitbits/git-shift/master/git-shift

perl git-shift +5h 2e6fd0a9dc98403c4fca638e411b3451cbc66a89

UPD2： 您可以创建自定义别名以自动转移所有新提交。为此，将以下行放入您的 ~/.bashrc 文件中

alias future-commit='git commit --date "$(date -v +4H)"'

或

alias future-commit='git commit --date "$(date -d +4hours)"'

重新加载终端，现在您将能够提交 +4 小时轮班：

future-commit -m "future commit"

Answer 2

您可以使用

在任何日期、时间进行提交

GIT_AUTHOR_DATE='your date' GIT_COMMITTER_DATE='your date' git commit -m 'message'

'your date' 的格式类似于Fri May 01 19:32:10 2015 -0400。

请注意author and committer are different entities in git 术语，因此需要设置两个时间戳（与其他 cmets 和答案中提供的选项不同）。

一般来说，author_date 是被 github/in git log 等捡到的，committer_date 在你查看所有提交信息时是可见的，比如gitk。如果仅更改 author_date 有效，请使用 --date 选项作为其他答案点。

Answer 3

注意：如果您需要在非常遥远的将来推迟提交，Git 2.13.x/Git 2.14（2017 年第三季度）将满足您的需求。

Git 的源代码将时间戳称为无符号长整数。
在 32 位平台以及 Windows 上，unsigned long 不够大 捕捉“遥远的未来”的日期。

当然，对于 long 数据，它完全符合 C 标准 类型以引用 32 位整数。这就是time_t 数据类型的原因 存在：即使long是32位，它也可以是64位。
Git 的源代码只是对时间戳使用了不正确的数据类型，仅此而已。

请参阅commit 28f4aee、commit 1e65a98、commit dddbad7（2017 年 4 月 26 日）、commit cb71f8b、commit 1aeb7e7（2017 年 4 月 21 日）和 commit efac8ac、commit a07fb05、commit e467dc1（20 年 4 月 20 日） ) Johannes Schindelin (dscho).
请参阅 Ramsay Jones (``) 的 commit 3f78971（2017 年 5 月 8 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit b15667b，2017 年 5 月 16 日）}

使用uintmax_t 作为时间戳

之前，我们使用unsigned long 作为时间戳。这只是一个好 Linux 上的选择，我们隐含地知道unsigned long 是什么 用于time_t。

但是，我们希望为时间戳使用不同的数据类型，原因有两个：

• 没有什么说 unsigned long 应该是与 time_t 相同的数据类型，实际上，例如在 64 位 Windows 上，它不是：
  unsigned long 是 32-位，但 time_t 是 64 位。

• 即使在 32 位 Linux 上，unsigned long（因此 time_t）是 32 位，我们希望能够在 Git 中编码当前荒谬的时间戳在遥远的未来，即使系统库无法将这些时间戳格式化为日期字符串。

因此，让我们切换到可用的最大整数类型，对于当今的所有实际用途，它至少应该是 64 位。肯定不能比unsigned long差，所以……

这是基于commit dddbad7（此补丁的一部分）：

timestamp_t: 一种新的时间戳数据类型

Git 的源代码假定 unsigned long 至少与 time_t。这是不正确的，并且会导致很多问题，尤其是 其中 unsigned long 仅为 32 位（尤其是在 Windows 上，即使在 64 位 版本）。

所以让我们改用更合适的数据类型。
在准备 为此，我们引入了新的timestamp_t 数据类型。

由于我们将使用不一定与time_t 相同的数据类型， 每当我们与 系统函数，以及其他任何地方的timestamp_t。

---

请注意，在 Git 2.24（2019 年第四季度）之前，新的 timestamp_t 类型存在缺陷。

见commit 2e09c01（2019 年 9 月 24 日）SZEDER Gábor (szeder)。
帮助者：Johannes Sixt (j6t)。
^{（由 Junio C Hamano -- gitster -- 合并于 commit 0b4fae5，2019 年 10 月 9 日）}

name-rev: 避免截止时间戳下溢

当使用 commit-ish 参数调用“git name-rev”时，它会尝试保存一些工作，并且不会访问早于最旧的给定提交的提交者日期减去一天的 slop 的提交。
由于我们的 'timestamp_t' 是无符号类型，当最早的给定提交的提交者日期在 UNIX 纪元的一天内时，这会导致时间戳下溢。
因此截止时间戳结束在遥远的未来，'git name-rev' 不会访问任何提交，并将每个给定的提交命名为 'undefined'。

检查从最早的提交者日期中减去斜率是否会导致下溢，在这种情况下不使用截止。
我们没有TIME_MIN 常量，dddbad7（timestamp_t：一种新的时间戳数据类型，2017-04-26，Git v2.14.0-rc0）没有添加，所以现在就添加。

请注意，截止timestamp变量的类型曾经在5589e87之前签名（name-rev：将“long”变量更改为timestamp_t，2017-05-20，Git v2.14.0 -rc0).
即使在那时，行为仍然相同，但是当从最早的提交者日期中减去斜率时，没有发生下溢，而是在将签名的截止时间戳与 name_rev() 中的未签名的提交者日期进行比较时。
IOW，这个下溢错误与“git name-rev”本身一样古老。