根据 git rebase doc。
可能出了什么问题?(A = A' = A'')
编辑:为了让自己更清楚,我们假设 F 撤消了 A' 的更改。现在 rebase 将不会在 F 上应用 A 补丁,只会应用 B' 和 C'。在这种情况下,git rebase 的行为可能是意外的,对我来说没有意义。
我无法理解的是这种优化的必要性是什么? 如果 Git 进行了变基操作,例如:If the upstream branch already contains a change you have made (e.g., because you mailed a patch which was applied upstream), then that commit will be skipped. For example, running git rebase master on the following history (in which A' and A introduce the same set of changes, but have different committer information):
A---B---C topic / D---E---A'---F master
will result in:
B'---C' topic / D---E---A'---F master
A''---- B'---C' topic
/
D---E---A'---F master
可能出了什么问题?(A = A' = A'')
编辑:为了让自己更清楚,我们假设 F 撤消了 A' 的更改。现在 rebase 将不会在 F 上应用 A 补丁,只会应用 B' 和 C'。在这种情况下,git rebase 的行为可能是意外的,对我来说没有意义。
A
在上游有一个补丁ID等效项A'
,在您的示例中。这是一种机制,而不是一种策略,但它达到了一个未声明的策略目标:即上游接受后跟上游撤消意味着您的补丁将不会被包含。 - torekgit rev-list
来获取 format-patch 的提交记录(或直接调用 format-patch),将结果传输到git am -3
,然后有人发现上游的 cherry-pick 失败了。因此,修改了git rebase
以省略上游的 cherry-picks。这被认为是正确和可取的,并一直保持这种方式。它失败(或曾经失败)的事实已经成为一种设计选择。但这只是猜测:它是一个有效的设计选择,并符合我所描述的策略。 - torek-k
选项适用于旧的git rebase
;新的git rebase
仍然有一个-k
,但它的工作方式有些不同,因为常规的rebase已经保留了“空”提交,而-k
只是强制rebase保留一个新的提交,该提交变为空。我稍微更新了答案。 - torek