重置失败后,git rebase blob

时间:2013-12-16 23:22:13

标签: git git-rebase git-reset

我使用GitHub for Windows创建了一个Git存储库,并在提交文件之前进行了重置,现在我丢失了所有的项目/文件。

我找到带

的文件
$ git fsck --lost-found

我的文件位于.git\lost-found\other,我可以使用$ git show SHA查看这些文件但是当我执行$ git rebase SHA时,我得到了这个:

  

错误:对象SHA是blob,而不是提交
  致命的:需要单一的修订版   上游SHA无效

我该怎么做才能恢复我的文件?

或者,可以用其他程序或语言读取文件吗?

1 个答案:

答案 0 :(得分:2)

我对git恢复一般不太熟悉,但你可能想看一下这个stackoverflow问题:

Accidentally reverted to master, lost uncommitted changes

假设您没有git addgit stashgit commit您的更改。所以我认为上述问题的公认答案中概述的方法都不起作用。

根据您的说法,执行git fsck --lost-found后,您的文件现在位于.git\lost-found\other文件夹中,您可以使用git show <SHA1>查看blob。 git rebase仅适用于提交,而不适用于blob,这就是它无效的原因。

我认为最安全的方法是编写脚本或为每个blob手动执行git show并将输出传递给文件。假设有一个名为4156fb7a的blob,它最初是存储库中的README.txt文件。你会这样做:

git show 4156fb7a > README.txt

这样blob的内容现在输出到README.txt。如果你手动完成这个过程将是乏味的,但这可能是一种安全的方法。

我认为.git\lost-found\other文件夹中没有的任何内容都可以假设丢失了。记得早点经常做。希望有所帮助。

编辑更新答案:

@Malaka,如果没有很多blob,你可以自己检查一下。否则,这只是猜测,但我猜你可能没有修改所有900个文件。如果你记得你修改了什么,那么修复工作就容易多了。否则,您可能想看看我的建议。

我要建议的是可能会或可能不会成功的事情。它假设存在原始文件的另一个文件夹,无论该文件夹是git repo还是其他。如果你没有其他pristine文件夹/ repo,那么下面我的想法是没用的。

第1步:

编写应用某些校验和的计算机程序,例如SHA1(使用sha1sum实用程序;如果不存在,请使用md5sum),在pristine文件夹中的每个文件上。该计算机程序最终将生成具有以下格式的文本文件:

fullFileName<SP>SHA1 checksum

<SP>代表空格。所以,假设我在原始文件夹/ repo中有以下文件:

app/controllers/ApplicationController.rb
assets/utilities.js
README.markdown

然后您的程序将生成一个类似于以下内容的文件。校验和当然都由当然组成:

app/controllers/ApplicationController.rb 01dfea13
assets/utilities.js 55a31aae
README.markdown 9671c6a0

从现在开始,我们将上述文件称为checksumfile

我希望您的原始文件不使用空格。如果有,只需使用其他分隔符来分隔文件名及其校验和。

第2步:

现在,编写另一个计算机程序(我们称之为blobCat),将git show应用于.git\lost-found\other文件夹中的每个blob,并将它们输出到另一个文件夹中的某些任意命名文件。我们将unknownBlobs表示该文件夹。为简单起见,您可以将它们输出为0.txt1.txt2.txt等等,换句话说,只需使用一些整数计数器来命名它们。

完成后,编写另一个读入checksumfile的程序,并使用字典将校验和索引到原始文件名。换句话说,鉴于上面的checksumfile,我们将生成以下字典/散列:

"01dfea13" => "app/controllers/ApplicationController.rb" 01dfea13
"55a31aae" => "assets/utilities.js" 
"9671c6a0" => "README.markdown" 

现在,遍历unknownBlobs程序生成的blobCat文件夹(包含所有0.txt1.txt2.txt文件的文件夹),然后申请与生成checksumfile时第一步中的校验和实用程序相同。如果在字典中找到校验和,这意味着blob 非常可能最初是该文件,您可以安全地将其还原到另一个文件夹中的层次结构。如果存在校验和冲突,您可能希望检查是否存在具有相同校验和的另一个blob,尽管这种情况不太可能发生。

对于unknownBlobs文件夹中没有在字典中找到校验和的任何blob,这可能意味着以下任何一种:

  1. 它是从原始存储库中存在的某个文件修改的
  2. 它不是存储库的一部分
  3. 这是一个从未被跟踪过的新创建的文件
  4. 在任何情况下,只需跟踪字典中找不到的那些blob,并在所有内容的末尾输出它们的名称。这应该是一组相当小的blob,因此您可以手动检查它们并确定它们是否属于原始存储库,然后将它们复制到目标位置。

    上述声音听起来很乏味但我觉得它比试图自己检查所有斑点要快得多,假设有很多斑点。