在交互式重基后查找原始git提交哈希

假设我从一个简单的git存储库开始，它有两个提交：

A --> B

然后，我对存储库执行一个交互式的重基，修改B，并在a和B之间添加一个提交。C是一个新的提交，D是对B的修改

A --> C --> D

B和D的提交消息不同，提交的代码也不同

是否有可能确定D是从B派生的？本质上，给定散列ID D，是否可以获得散列ID B

我怀疑答案将使用reflog，可能是通过

git log-g

，但我无法将重新设置的提交映射到原始提交

如果默认情况下不可能，是否可以通过配置更改获得信息

似乎可以通过

post rewrite

钩子获得此信息，但是，这仅在您预期需要此信息时有效

是否有可能确定D是从B派生的？本质上，给定散列ID D，是否可以获得散列ID B

不，或者更确切地说，不是直接的：

我怀疑答案将利用reflog

reflog包含的信息是您进行了重新基化，以及

B

的原始SHA-1，但不包括在进行重新基化的过程中拆分提交的事实。你可以试探性地确定这一点（通过扫描reflog，比较前后ID，并通过父ID SHA-1从

HEAD

和

B

的reflog条目向后移动：您会发现commit

A

在前后都存在，

B

在前后都存在，

C

和

D

在之后都存在）.Commit

B

本身保留在存储库中，直到其reflog条目过期，因此您需要执行这种启发式扫描的时间

---

您可能还会发现提交

D

时的作者日期与提交

B

时的作者日期相同（对此我一点也不确定）。

除非您将该信息保存在自己的某个位置。如果您是另一个分支，并且您

git cherry pick

某些内容，则会出现类似的情况。。。