2010-08-10 30 views
2

这就是情况:我在git存储库中失去了一些工作,这项工作曾经被提交过,但现在被埋在我的历史记录中,某处这可能无法通过'git log --all'。 我唯一能记住的就是一些不同的字符串,这个字符串可以指出一个文件,这个文件是我工作的一部分。如何查找包含包含给定字符串的文件的树的提交SHA1

我有一个解决方案...但它是相当长的,你有更好的解决方案?

这是我的解决方案:

我设法找到我按配料几个命令提交SHA1:

  • 首先找出所有“斑点”的对象中的.git /对象,“git的猫'他们(和使用grep)找到包含我的文件的BLOB的SHA1。
  • 然后,我不得不解析所有的'树'对象,以找到哪些包含文件的SHA1 ...直到包含在没有其他'树'对象的树对象。
  • 最终解析包含此根树的所有提交。
+0

http://stackoverflow.com/questions/2839253/git-history-find-lost-line-by-keyword – simplyharsh 2010-08-10 16:51:48

+2

@simplyharsh:这个问题是不同的 - 提交可能无法从任何分支到达。 – Cascabel 2010-08-10 17:09:21

回答

7

如果提交可从某个ref中获得,那么最佳解决方案肯定是镐搜索:git log -Sstring --all

如果无法访问,您是对的,您将不得不做一些挖掘工作。如果你认为你有散落在整个地方的承诺,最简单的做法是使用git fsck --lost-found找到你悬挂的提交。 (它也会打印晃来晃去的斑点。)然后,您可以在每个这些SHA1上使用git grep <commit>,并找到您的字符串。另一方面,如果你认为你有几个候选分支被修剪,并且你的目标将会在其中一个分支上,那么我会使用git reflog show来回顾你的推荐日志,找到提交的提交他们的提示,并重新创建它们,所以你可以做git log -Sstring <branches> ^master

+0

对不起,这不能解答我的问题:你的3个选择是基于一个被认为是未知的信息:“是否在可达分支提交?”。你不提供更简单的方法,但我同意可能没有。 – vaab 2011-10-07 12:57:01

+0

即使你不知道它是否可达,你应该总是先试着用'git log',因为它会更快,更快。第二个选择不依赖于从refs可达 - 事实上,它只列出了*不可*的提交。它**是答案,它比你的方法更好,因为它避免了检查可*到达的blob。第三个是妥协,因为当他们目前无法到达,但你有一个想法在哪里看,因为fsck是耗时的。 – Cascabel 2011-10-07 15:51:14

相关问题