`git rebase-i`,交互列表中缺少几个正常提交

`git rebase-i`,交互列表中缺少几个正常提交,git,Git,环境:macOS 10.14.2上的git版本2.17.1 您可以克隆存储库以进行测试: git clone https://gist.github.com/arzyu/9c4a50257bd2be18ed1e9774b7600070 rebase-demo git日志: * 32b845d (origin/b2, b2) C7 | * be5dd19 (origin/b1, b1) C6 |/ | * 166caa4 (HEAD -> master, origin/master) C5

环境:macOS 10.14.2上的git版本2.17.1

您可以克隆存储库以进行测试:

git clone https://gist.github.com/arzyu/9c4a50257bd2be18ed1e9774b7600070 rebase-demo
git日志:

* 32b845d (origin/b2, b2) C7
| * be5dd19 (origin/b1, b1) C6
|/
| * 166caa4 (HEAD -> master, origin/master) C5
| * 27bb508 C4
| * 63aed5a C3
|/
* 1ed4bc4 C2
* 8ff08b7 C1
案例1:

# on master
git rebase -i b1


# list 1
pick 63aed5a C3
案例2:

# on master
git rebase -i b2

# list 2
pick 63aed5a C3
pick 27bb508 C4
pick 166caa4 C5

为什么列表1中没有显示
C4
C5

编辑:克隆存储库证明理论正确;见下文增编

这里的问题是,rebase决定了提交是冗余的。特别是,
git-rebase
(带或不带
-i
)将省略上游提交为“补丁等效”的提交

也就是说,假设我们有:

...--F--G--H2--J2--K   <-- upstream
         \
          H--I--J   <-- branch
然而,当Git准备要复制的提交哈希ID列表时,它会做一些稍微棘手的事情:对于每个提交
H
I
J
,它会检查是否有任何上游只在这里提交,
H2
J2
,和
K
-具有与提交
H
I
J
相同的
git补丁id

git show <hash> | git patch-id
这似乎就是你所观察到的。不过这有点奇怪,因为这意味着提交
C4
C5
必须具有相同的补丁ID
b1
上只有一个上游提交,即
C6
。只有当它们都具有相同的补丁ID并且与
C6
的补丁ID相同时,才能消除它们

(显然,
C7
的补丁ID是不同的,因此rebase保留了所有提交。)

补遗 左侧的散列ID是补丁ID,而右侧的散列ID是提交ID(分别用于C3、C4和C5)。例如:

$ git show master~2
commit 63aed5a10cf22e1dd1ba699dac9104f3605a3751
Author: arzyu <arzyu@live.cn>
Date:   Mon Dec 17 17:17:01 2018 +0800

    C3

diff --git a/test.txt b/test.txt
index 4b87763..a25c784 100644
--- a/test.txt
+++ b/test.txt
@@ -1,2 +1,4 @@
 //
 //
+
+//
由于所有三个提交都有补丁ID
c711e5dfe43107af9bcff6c00bed4211d3b60cf6
git-rebase
忽略了否则将被复制的两个

提交的补丁ID如下所示:

只不过是相关文件差异的SHA-1之和 使用补丁,忽略空白和行号


因为所有三个补丁都只是添加了一行,由
/
组成,它们都有相同的补丁ID,Git假设它在做正确的事情时忽略了它们以进行重新基化。

C4和C5合并了吗?@evolutionxbox否,它们是正常的提交。我无法复制您的问题。。。我创建了一个具有相同树结构的小型回购,在master上运行
git-rebase-I b1
,我看到提交了C3、C4和C5。您使用了我的gist-repo吗?你可以克隆它进行测试。不,我用的是我自己的,它和你的树结构一样。(假设它们都是正常提交)您可以克隆它:
git clonehttps://gist.github.com/arzyu/9c4a50257bd2be18ed1e9774b7600070 git-rebase-i-demo
Aha,克隆它表明它实际上就是补丁ID。是的,你说对了!谢谢你回答得这么清楚。另一个谜团被@torek解开并彻底解释了。荣誉
                     I2   <-- branch
                    /
...--F--G--H2--J2--K   <-- upstream
         \
          H--I--J   [abandoned]
$ git clone https://gist.github.com/arzyu/9c4a50257bd2be18ed1e9774b7600070 gri
$ git show master~3..master | git patch-id
c711e5dfe43107af9bcff6c00bed4211d3b60cf6 166caa401ede4f97841a2715a80b4d26c40c50b8
c711e5dfe43107af9bcff6c00bed4211d3b60cf6 27bb50839ee73bce4cbb97089306c5dfa04c4516
2ee54397f45e5f955fc7b5b6717544e526818ede 63aed5a10cf22e1dd1ba699dac9104f3605a3751
$ git show master~2
commit 63aed5a10cf22e1dd1ba699dac9104f3605a3751
Author: arzyu <arzyu@live.cn>
Date:   Mon Dec 17 17:17:01 2018 +0800

    C3

diff --git a/test.txt b/test.txt
index 4b87763..a25c784 100644
--- a/test.txt
+++ b/test.txt
@@ -1,2 +1,4 @@
 //
 //
+
+//
$ git show origin/b1 | git patch-id
c711e5dfe43107af9bcff6c00bed4211d3b60cf6 be5dd192f9bed20036491915766be61d66eec8aa
$ git show origin/b1
commit be5dd192f9bed20036491915766be61d66eec8aa (origin/b1)
Author: arzyu <arzyu@live.cn>
Date:   Mon Dec 17 17:19:09 2018 +0800

    C6

diff --git a/test.txt b/test.txt
index 4b87763..b8e0885 100644
--- a/test.txt
+++ b/test.txt
@@ -1,2 +1,3 @@
 //
 //
+//