【问题标题】:How can I fix "bad date" issues in a git repository?如何修复 git 存储库中的“错误日期”问题?
【发布时间】:2020-04-01 12:27:48
【问题描述】:

我最近尝试将存储库导入 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 大师会关心引导我朝着正确的方向前进吗?

【问题讨论】:

    标签: git corruption git-fsck


    【解决方案1】:

    作为illustrated heregit 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 is declared deprecated,考虑newren/git-filter-repo 修复那些作者/提交者,如in here

    但是:历史将被重写,在您的情况下(迁移)可能没问题。

    【讨论】:

      【解决方案2】:

      天哪,这是怎么回事?

      有人使用了不良版本的 Git(或构建 Git 对象的不良工具)。谁、何时、如何等,是不可能的,但如果你检查各种错误的提交,那可能会提供一些非常大的线索,因为错误的行应该有这种一般形式:

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

      或:

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

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

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

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

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

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

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

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

      【讨论】:

      • 好的,谢谢@torek。幸运的是,我是一个孤独的开发者,所以我将是唯一受此影响的人。我的原始存储库在 BitBucket 上,无论如何我都计划将其迁移到 GitHub,这样就可以为我提供一个有用的断点,我可以在其中进行所有修复。我很可能使用 Atlassian 的 SourceTree 作为该存储库的 Git 客户端,而且几乎可以肯定是我在进行提交。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-09-11
      • 1970-01-01
      • 2022-01-05
      • 2012-01-06
      • 2012-05-27
      相关资源
      最近更新 更多