3

我最近尝试将存储库导入 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.

天哪，那是怎么发生的？我什至不知道如何开始解决这个问题。搜索“bad date”并没有得到任何有用的建议。

一位好心的 git guru 会愿意引导我朝着正确的方向前进吗？

4

2 回答 2

2

如此处所示，agit cat-file将有助于查看作者/提交者的格式

例子：

'git log' 不会按原样显示提交对象的标头，但 'git cat-file' 会：

  $ 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已声明 deprecated，请考虑newren/git-filter-repo修复这些作者/提交者，如此处。

但是：历史将被重写，在您的情况下（迁移）可能没问题。

于 2019-12-08T00:23:11.797 回答
2

天哪，那是怎么发生的？

有人使用了不良版本的 Git（或构建 Git 对象的不良工具）。谁、何时、如何等，无法说清楚，但如果你检查各种错误提交，那可能会提供一些非常大的线索，因为错误行应该具有以下一般形式：

author A U Thor <thor@example.com> 1575578639 -0800

或者：

committer A U Thor <thor@example.com> 1575578639 -0800

日期和时间戳是最后两个数字字段。介于两者之间的内容可能会告诉您谁来询问他们使用的 Git 版本。

我什至不知道如何开始解决这个问题。

从技术上讲，您无法自己修复错误的提交。原因是，无论好坏，提交中的原始数据都是提交的哈希 ID 的来源。由于hash ID是commit的真实姓名，commit的真实姓名要求commit的数据是bad的。如果您确实修复了它们，它们将成为不同的提交，它们将具有不同的哈希 ID 名称。

正如VonC 所说，要生成一个新的、不兼容但已更正的存储库，您必须将这些错误提交中的每一个替换为新的和改进的提交，可能使用git filter-branch或使用新的git filter-repo. 无论您使用什么工具或方法，您都需要提供一些方法来替换错误提交的提交标头中的错误author和/或committer行，使用新的正确行——满足 Git 内部要求的日期和时间戳。

用更正的提交替换了错误提交后，您现在还必须替换每个后续（后代）提交，因为这些提交的直接子代将其父哈希 ID（错误提交的那些）作为数据的一部分存储在其中。因此，您必须编写一个新的更正子提交，以保留除父哈希 ID 之外的所有内容。这会使子提交的子提交无效，因此也必须重写这些子提交，依此类推：所有后代提交。

这正是这些 filter-branch / filter-repo 工具所做的。您（以某种方式）在存储库中挑选出一个错误的提交，然后他们将其复制到一个新的和改进的提交中。然后他们也复制原始错误提交的所有后代，以便从更正的提交中下降一个新的家谱。

由于存储库中的一组提交是该存储库中的历史记录，因此复制所有这些提交的结果是一个全新的历史记录——一个新的存储库，旧存储库的所有用户现在必须切换到使用它。因此，更正存储库的技术部分通常是整个过程中最简单的部分。找出问题所在以及如何使用这些工具来重写历史需要一些工作，但您只需这样做一次就完成了。但是，您必须跟踪旧存储库的每个用户，并以某种方式说服他们停止使用该存储库并开始使用新的和改进的存储库。

于 2019-12-08T01:00:27.027 回答