代码之家 › 专栏 › 技术社区 › raisercostin

日期在1973年之前的git提交失败[duplicate]

epoch git

raisercostin · 技术社区 · 7 年前

但是,当我尝试以下操作时:

git commit -m "this is a test commit" --date="1960-04-07 18:00:00"

我收到一个“致命:无效日期格式”错误。

这不是很实用(我不是时间旅行者),但我一直在想,是否可以将git用于历史目的。这可以用git管道命令强制执行吗?一个相关的问题是:git总是使用32位的时间戳,还是这取决于它构建的环境?

0 回复 | 直到 11 年前

VonC 7 年前

远在 commit c64b9b8

<date>

epoch '

commit 6eb8ae0 将日期定义为 unsigned long 自2005年4月以来。

可以存储unix epoch之前的日期,但不能确保正确表示。

但自2014年以来,这一点已经发生了变化(见下文)

试图代表一个日期之前 this thread

--date 用ISO8601标记:上面写着 " invalid date ".

git ml archive

git commit
git cat-file -p HEAD > tmp.txt
# at this point, edit the file to replace the timestamp

git hash-object -t commit -w tmp.txt
#=> 2ee8fcc02658e23219143f5bcfe6f9a4615745f9
git update-ref -m 'commit: foo' refs/heads/master \
    2ee8fcc02658e23219143f5bcfe6f9a4615745f9

提交日期已有效更新,但是 git show Jan 1 1970 ). tig(1) 显示器 55 years ago 因此实际提交日期被正确地存储。

#=> remote: error: object 2ee8fcc02658e23219143f5bcfe6f9a4615745f9:invalid
#       author/committer line - bad date
#=> remote: fatal: Error in object
#=> error: unpack failed: index-pack abnormal exit

最后,在跑步时 test-date 来自git源:

./test-date show -354808800
#=> -354808800 -> in the future

这个 discussion at the time 提到:

我不确定在最底层是否存在某种不可移植性。
我们可以在低级日期代码中的time_t和unsigned long之间自由交换。这很可能是因为在有符号和无符号类型之间来回转换位通常是有效的,只要最终得到所需的类型。
See, for example, my recent 9ba0f033 .

无符号长 “收件人” long long time_t ,甚至“ gittime_t “如果我们想抽象它)。

并且至少在 tm_to_time_t()

它是不只是“ sed s/unsigned long/long long 类型。
这就是为什么没有人这么做。;)

Use future date while making git commits ,Git已经开始采用一种不同于 timestamp_t

如中所示 Legilibre/Archeo-Lex issue 47

日期现在使用 时间戳 typedef uintmax_t timestamp_t; ,代替 无符号长 键入,以修复32位平台上的某些问题。。。和Windows 64位^^。

项目 archeo-lex.fr Legilibre/Archeo-Lex-web .
现在(2019年2月)完成了,因为 commented 通过 Seb35

patbarron 12 年前

Git内部将日期作为Unix时间戳和UTC的偏移量进行维护,因此无法在Unix时间纪元之前设置提交日期。

你运行的Git版本一定和我在CentOS 6.5系统(它提供了Git 1.7.1)上的版本不同,至少你的系统会给你一条错误消息。。。如果我尝试使用git1.7.1设置一个不可能的提交日期,那么提交会成功,并以当前时间作为提交日期;如果我使用“可能的”提交日期尝试相同的操作,它会成功并记录预期的提交日期。

Joe 12 年前

你可以存储它们,但是没有任何东西能像你期望的那样显示出来。

内部Git格式将提交数据存储为数字字符串。例如。:

$ git cat-file -p aa2706463fdeb51d6f9d0e267113b251888cf7f5
...
author Junio C Hamano <gitster@pobox.com> 1383318892 -0700
committer Junio C Hamano <gitster@pobox.com> 1383318892 -0700

git ,将其解析为无符号数字,并且不会正确显示这些日期。例如, in builtin/blame.c :

    *time = strtoul(ident.date_begin, NULL, 10);

John O 12 年前

我只是在git hash对象上闲逛,创建了以下提交对象:

tree 5efb9bc29c482e023e40e0a2b3b7e49cec842034
author x <x@x.com> -134607600 -0500
committer z <z@z.com> 1402404632 -0600

blah blah

$ git log
commit 2303e7012001a3cc1c3dec806d0902008e1257a8
Author: x <x@x.com>
Date:   (null)

    blah blah

Parents: 
Author: x <x@x.com>
Date: Monday, January 01, 0001 12:00:00 AM
Committer: z <z@z.com>
Commit Date: Tuesday, June 10, 2014 7:50:32 AM

(我想我忘了包括父提交对象…)

同样地,如果它不是一个表示未来的值,那么它也可能是。

我不确定这个答案是否符合“不,你不能这样做”或“你可以,但它不起作用”。我们需要一个修改过的客户机才能看到带有正确日期的git日志,从而消除任何可能的好处。如果有人知道一个漂亮的git log命令,它可以正确地解析这些时间戳(它们在那个时候消失了吗?!)请纠正我。