Question

通常当两个分支在相同的源代码状态下重合时，它们将散列相同并显示为折叠在一起。但我发现自己处于一个有趣的状态（标题中描述）。

我是如何到达那里的。我上周有一个旧分支，我将很多变化从master合并到它。在这一点上，它是一个快速前进，而且与主人没有任何区别。

但是当我将一个功能分支合并到这个分支中时（它几乎与主分支具有相同的状态），它最终会像这样：

* b0dc045 - (new-branch) refactored it. seems to work fine
| * 4b89219 - (HEAD -> feature, origin/feature) refactored it. seems to work fine
|/
* Merge branch 'master' into 'feature'
|\
...

＆＃39;主＆＃39;在某个地方下面......

所以无论如何，git diff new-branch feature显示没有差异......但他们有不同的哈希......

我可以检查哪些东西真正看到它们真正的不同之处？

更新

我猜分支历史的各个方面都包含在生成哈希的数据集中。这可以解释这种差异。

所以我做了一个快速而又肮脏的把戏

$ diff <(git log new-branch) <(git log feature) 
1c1
< commit b0dc045b82cfc2f7060ccd3b28dd1b1ca1cf2a59
---
> commit 4b8921960cc8f1d42e3e4d1b505228a2dc0c0638

它表明第一行的哈希值不同。这是令人费解的部分。它还显示24000行git log的其余部分是相同的。

Answer 1

这是因为提交消息，时间，作者和父提交ID是散列的一部分。这确保了在发布提交并在其上进行进一步开发之后，没有人可以更改这些字段。

但是，当然，它还允许您根据需要与尽可能多的不同作者，提交时间，消息和历史重新声明相同的状态。每次，您将获得不同的哈希值，从而获得没有内容差异的另一个提交。

Answer 2

获得命令

的@larsks

$ git cat-file -p new-branch; git cat-file -p feature; 
tree 26e6e56076b5578100857218df0cbed7fcab10a3
parent 72f868f7fd45ecabef78cab23f120d48a04bf38d
author Steven Lu (PuTTY Win7 on Centos 7 VM Feb26[tmux]) <stevenlu443@gmail.com> 1439228778 -0400
committer Steven Lu (Centos 7 VM Feb26) <stevenlu443@gmail.com> 1439230770 -0400

refactored it. seems to work fine
tree 26e6e56076b5578100857218df0cbed7fcab10a3
parent 72f868f7fd45ecabef78cab23f120d48a04bf38d
author Steven Lu (PuTTY Win7 on Centos 7 VM Feb26[tmux]) <stevenlu443@gmail.com> 1439228778 -0400
committer Steven Lu (Centos 7 VM Feb26) <stevenlu443@gmail.com> 1439228778 -0400

refactored it. seems to work fine

delta位于new-branch的提交时间内。

那个疯狂的maaaaan。

两个分支与git diff相比较，但具有不同的哈希值

2 个答案: