为什么 git 认为 HEAD 是 17 年前的第一次提交？答案

【问题标题】：Why does git think HEAD is the first commit from 17 years ago?为什么 git 认为 HEAD 是 17 年前的第一次提交？
【发布时间】：2017-06-01 00:29:06
【问题描述】：

我正在尝试收集[NOW, THEN] 范围内的提交列表，其中NOW 是HEAD，[THEN] 是8af39377，它大约是120 次之前的提交。

>  git log 8af39377289feba1876b3252b6d23 HEAD --oneline | cut -d " " -f 1 > commits.txt

然后查看commits.txt，它有 2300 行长，顶部条目显示为 8af39377（THEN），底部条目显示为 a3b6ece（2002 年的第一次提交）。

为什么 Git 认为 HEAD 是第一次提交到存储库？

【问题讨论】：

赞成使用 Git 17 年。
@TimBiegeleisen - 谢谢。迁移后。
请查看 stackoverflow.com/questions/462974 的第二个答案。它演示了 A..B 和 A...B。 git log A B 是集合 {A, B} 或 A∪B。
ps。添加--graph 使完整输出更清晰（删除管道切割）。

标签： git commit

【解决方案1】：

您的语法错误。如果你想要 8af39 和 HEAD 之间的范围，那么你需要8af39..HEAD

至于为什么它显示在 17 年前，如果您只指定一个修订版，它会发现该提交的所有提交 REACHABLE。由于所有提交都有指向根的反向指针，因此您正在找到根提交。

Revision Specification 请参阅指定范围部分。

【讨论】：

我想这并不奇怪......我按照<commit hash 1> <commit hash 2> 的引用答案的说明进行操作，它产生了上面的输出。您的答案不会产生任何输出。 Git 不会产生警告或错误也就不足为奇了。多么可怜的工具……
你能帮我核实几件事吗？ 1）您确实使用了 2 个点而不是 3 个点？ 2) 你的 HEAD 确实在 8af39 之后？只是想确保提交的顺序是正确的。 3）HEAD /您当前的分支确实可以访问8af39。确保您只使用git log blah blah 命令来消除cut 作为错误源。
有一个额外的细节我必须提到。如果 HEAD 不是合并提交，则此方法有效。如果 HEAD 是合并提交，那么我给您的命令的结果还将包括 8af39 可能无法访问的提交。它可以列出一些比合并库更新的额外提交。

【解决方案2】：

git log 8af39377289feba1876b3252b6d23 HEAD --oneline

这就是说“给我这两个提交的全部历史记录，按祖先限制的日期顺序排序”。

你想要

[NOW, THEN] 范围内的提交列表，其中 NOW 是 HEAD，[THEN] 是 8af39377，大约 120 次之前的提交

但是您的日志输出与您的哪个是矛盾的：git log 首先显示其最近的输出，受祖先限制，并且

它显示顶部条目为 8af39377。

所以你的提交顺序是错误的。如果您没有将默认输出设为静音，它也会显式地向您显示提交日期，因此您会看到它是日期问题还是祖先问题。

不管它是什么，

git log --oneline HEAD..8af39377

将显示列表。

可能值得添加--graph --decorate。

【讨论】：

认为这是倒退，不是吗？ 8af39377 是 HEAD 之前的 120 次提交。 HEAD..8af39377 是可从 8af39377 访问的提交，不包括可从 HEAD 访问的提交。所以你在这里排除了 8af39377 之后的东西。
正如我所说，您的日志输出与您的观点相矛盾：8af39377 首先出现，这意味着它不是 HEAD 的祖先（否则 HEAD 会先出现）和有一个更新的日期（否则 HEAD 会先出现）。顺便说一句，您的cut 只是为您提供提交ID，如果您想要列出revs，为什么不使用git rev-list（git log's - 以及许多其他修订版 -步行命令'）更专注于激光的父亲）或git log --pretty=%H？
你没有和 op 说话。虽然我想知道你认为 git log commit1 commit2 做了什么。实际上，文档似乎对应该发生的事情有点模糊，但我认为 commit1 被视为提交，而提交 2 被视为路径，因为它是树状的并且将解析为根树对象
续：在这种情况下应该首先出现 8af39