假设我有一个这样的图

A---B---C---D (master)
     \
      \-E---F (HEAD)

如果我执行git log -all - online,我将得到所有6次提交。

但如果图像是

A---B---C---D (master, HEAD)
     \
      \-E---F

我不会看到E和f。我能得到git告诉我所有的提交,包括那些没有命名的分支吗?

谢谢


当前回答

我怎么解决这个问题?使用git fsck和日志!

首先创建一个包含丢失(不可达)提交和blob的文件。(注意:如果你做了像git gc这样的事情,那么它会垃圾收集所有提交的文件,你在这里找不到它们!)

$git fsck --lost-found > lost_found.commits

它会给你一个这样的文件:

悬空提交dec2c5e72a81ef06963397a49c4b068540fc0dc3 悬浮blob f8c2579e6cbfe022f08345fa7553feb08d60a975 悬挂blob 0eb3e86dc112332ceadf9bc826c49bd371acc194 悬挂blob 11cbd8eba79e01f4fd7f496b1750953146a09502 悬空提交18733e44097d2c7a800650cea442febc5344f9b3 悬挂blob 1e53a5cdb3ecdde27081ec6e8b31e4070106ee05

然后,您可以使用您喜欢的文本编辑器打开该文件,从那里复制提交/博客哈希值。(*咳嗽* vim宏工作为这个*咳嗽*)

现在你可以用git log——oneline <commit hash>之类的东西从这个提交中返回日志。 或者,gitk, tig或任何其他git查看器都可以工作。

在你的例子中,如果你找到提交F的哈希,日志会显示这样的东西,

A---B---E---F

又快又简单!现在您可以找到所有这些悬空提交背后的上下文。

附注:是的,我知道,很晚了,但哦,好吧,有人可能会在这里找到它,并发现它很有用。(很可能是我在6个月后再次谷歌这个)

其他回答

@bsimmons

git fsck --lost-found | grep commit

然后为每一个创建一个分支:

$ git fsck --lost-found | grep commit
Checking object directories: 100% (256/256), done.
dangling commit 2806a32af04d1bbd7803fb899071fcf247a2b9b0
dangling commit 6d0e49efd0c1a4b5bea1235c6286f0b64c4c8de1
dangling commit 91ca9b2482a96b20dc31d2af4818d69606a229d4

$ git branch  branch_2806a3 2806a3
$ git branch  branch_6d0e49 6d0e49
$ git branch  branch_91ca9b 91ca9b

现在,许多工具将向您显示那些丢失的提交的图形化可视化。

不是很容易——如果你把指针弄丢了,那就像大海捞针一样。你可以找到所有看起来不再被引用的提交- git fsck -unreachable将为你做这件事-但这将包括你在git提交后扔掉的提交- modify,你重新基于的分支上的旧提交等等。因此,一次查看所有这些提交很可能有太多的信息,难以处理。

所以轻率的回答是,不要忘记你感兴趣的东西。更严重的是,reflogs将默认保存您在过去60天左右使用过的所有提交的引用。更重要的是,它们将提供关于这些提交是什么的上下文。

Try:

git log --reflog

它通过假装reflogs (git reflog)提到的所有对象在命令行上被列出为<commit>来列出所有git提交。

实际上,git fsck可以用来找到所有丢失的提交,你只需要正确的选项:

git fsck --unreachable --no-reflogs

——unreachable单独是不够的,因为一些提交可能仍然被reflog引用。如果你需要对整个提交历史有一个非常清晰的视图,你可以创建一个别名,就像这样:

git log --all --decorate --oneline --graph $(git fsck --no-reflogs --unreachable | awk '{if ($2 == "commit") print $3}')

老实说,我不确定在最后一个命令中是否需要——unreachable选项,因为默认情况下git日志遍历祖先(除非指定了——no-walk)。我不敢打赌,但我认为没有必要。

我怎么解决这个问题?使用git fsck和日志!

首先创建一个包含丢失(不可达)提交和blob的文件。(注意:如果你做了像git gc这样的事情,那么它会垃圾收集所有提交的文件,你在这里找不到它们!)

$git fsck --lost-found > lost_found.commits

它会给你一个这样的文件:

悬空提交dec2c5e72a81ef06963397a49c4b068540fc0dc3 悬浮blob f8c2579e6cbfe022f08345fa7553feb08d60a975 悬挂blob 0eb3e86dc112332ceadf9bc826c49bd371acc194 悬挂blob 11cbd8eba79e01f4fd7f496b1750953146a09502 悬空提交18733e44097d2c7a800650cea442febc5344f9b3 悬挂blob 1e53a5cdb3ecdde27081ec6e8b31e4070106ee05

然后,您可以使用您喜欢的文本编辑器打开该文件,从那里复制提交/博客哈希值。(*咳嗽* vim宏工作为这个*咳嗽*)

现在你可以用git log——oneline <commit hash>之类的东西从这个提交中返回日志。 或者,gitk, tig或任何其他git查看器都可以工作。

在你的例子中,如果你找到提交F的哈希,日志会显示这样的东西,

A---B---E---F

又快又简单!现在您可以找到所有这些悬空提交背后的上下文。

附注:是的,我知道,很晚了,但哦,好吧,有人可能会在这里找到它,并发现它很有用。(很可能是我在6个月后再次谷歌这个)