我最近尝试将存储库导入GitHub(从Bitbucket(，但导入失败。GitHub 技术支持告诉我，他们在存储库中看到"错误日期"问题，我应该在存储库上运行git fsck。所以我从BitBucket克隆了它并运行了git fsck，这就是我得到的：
git fsck Checking object directories: 100% (256/256), done.
error in commit fda45b4b6b06f6b815341c1f26de827c769f48b6: badDate: invalid
author/committer line - bad date error in commit
636d259fd0ac343af2a5561ff799a54a6aeb9b1c: badDate: invalid
author/committer line - bad date error in commit
41dc786816992e3c42c904e8c848aa1078475386: badDate: invalid
author/committer line - bad date error in commit
c55a0fa0d98e02aa4621be202d7b7d21ed2ff2ab: badDate: invalid
author/committer line - bad date error in commit
e6ad8f5ea7cf6441b6ea6ab5583117113a8f49fb: badDate: invalid
author/committer line - bad date error in commit
4aea97fdd999484319a9fbbc4dc42b024e1eba80: badDate: invalid
author/committer line - bad date error in commit
531f7783e383868c1d52a1bf2dc3212f5e10a91c: badDate: invalid
author/committer line - bad date Checking objects: 100% (546/546),
done.
天哪，这是怎么发生的？我什至不知道如何开始解决这个问题。搜索"糟糕的约会"并没有产生任何有用的建议。
一个善良的git大师会愿意引导我朝着正确的方向前进吗？
天哪，这是怎么发生的？
有人使用了糟糕的 Git 版本(或构建 Git 对象的不良工具(。 谁，何时，如何等，不可能说，但如果你检查各种错误的提交，这可能会提供一些非常大的线索，因为坏行应该有这样的一般形式：
author A U Thor <thor@example.com> 1575578639 -0800
或：
committer A U Thor <thor@example.com> 1575578639 -0800
日期和时间戳是最后两个数值字段。 介于两者之间的内容可能会告诉您谁该问他们正在使用什么 Git 版本。
我什至不知道如何开始解决这个问题。
从技术上讲，您无法修复错误的提交本身。 原因是，无论是否错误，提交中的原始数据都是提交的哈希 ID 的来源。 由于哈希 ID是提交的真实名称，因此提交的真实名称要求提交的数据是错误的。 如果您确实修复了它们，它们将成为不同的提交，这些提交将具有不同的哈希 ID 名称。
正如 VonC 所说，要生成一个新的、不兼容但已更正的存储库，您必须将这些错误提交中的每一个替换为新的和改进的提交，也许使用git filter-branch或新的git filter-repo。 无论您使用哪种工具或方法，都需要提供某种方法来将错误提交标头中的错误author和/或committer行替换为新的正确行，即满足 Git 内部要求的日期和时间戳。
将错误提交替换为更正的提交后，您现在还必须替换每个后续(后代(提交，因为这些提交的直接子级将其父哈希 ID(错误提交的子级(作为其数据的一部分存储在其中。 因此，您必须编写一个新的更正子提交，以保留除父哈希 ID之外的所有内容。 这使子提交中的子提交无效，因此也必须重写这些子提交，依此类推：所有后代提交。
这正是这些筛选器分支/筛选器存储库工具的作用。 您(以某种方式(在存储库中挑选出一个错误的提交，然后他们将其复制到新的和改进的提交中。 然后，他们也复制原始错误提交的所有后代，以便从更正的提交中产生一个新的家谱。
由于存储库中的提交集是该存储库中的历史记录，因此复制所有这些提交的结果是一个全新的历史记录 — 一个新存储库，旧存储库的所有用户现在必须切换到该存储库才能使用。 因此，更正存储库的技术部分通常是整个过程中最简单的部分。 找出问题所在以及如何使用这些工具重写历史需要一些工作，但你这样做一次就完成了。 但是，您必须跟踪旧存储库的每个用户，并以某种方式说服他们停止使用该存储库并开始使用新的和改进的存储库。
如图所示，git cat-file将有助于查看作者/提交者的格式
例：
"git log"不会按原样显示提交对象的标头，而是"git 猫文件"确实：
$ git cat-file -p c609265ccce27a902b850f5d62e6628710ee2928
tree ea8e3bd64e67d159e706b8feccfc169f6ac0829d
parent db4e80ee11a4e212a97efc1761ed237c7da72cb1
author Richard W.M. Jones <rjones@xxxxxxxxxx> <"Richard W.M. Jones <rjones@xxxxxxxxxx>"> 1254739168 +0100
committer Richard W.M. Jones <rjones@xxxxxxxxxx> <"Richard W.M. Jones <rjones@xxxxxxxxxx>"> 1254739168 +0100
New translations.
由于git filter-branch已声明已弃用，因此请考虑newren/git-filter-repo修复这些作者/提交者，如此处所示。
但是：历史记录将被重写，这在您的情况下(迁移(可能没问题。