所以,假设我有一个实现了某些功能的书签,所以日志(hg graph --style compact -G)就像:
o 3[tip]:1 4fa205099913 2014-07-28 13:37 +0300 shabunc
| default commit C
|
| @ 2[feature] d3c4f62b33ca 2014-07-28 13:36 +0300 shabunc
|/ feature commit A
|
o 1 a06864113f47 2014-07-28 13:35 +0300 shabunc
| default commit B
|
o 0 d746532dac10 2014-07-28 13:35 +0300 shabunc
default commit A
在rhodecode中,我可以选择我要创建PR的书签。这是提交表单,让您了解我在谈论的内容:
在这种情况下,将有一个基于特征的变更集基于拉取请求(d3c4f62b33ca)。这是可预测和直观的。
但是现在假设你已经在书签下工作了一些功能但是远程仓库自那以后没有改变,所以你有这个日志图:
@ 2[tip][feature] d3c4f62b33ca 2014-07-28 13:36 +0300 shabunc
| feature commit A
|
o 1 a06864113f47 2014-07-28 13:35 +0300 shabunc
| default commit B
|
o 0 d746532dac10 2014-07-28 13:35 +0300 shabunc
default commit A
这是一个众所周知的恶意行为 - 即使在书签创建之后也没有引入新的更改,也不会创建新的头部。
但是现在,因为还没有创建头,尝试基于功能创建PR将最终在pull请求中进行所有三次提交。这不是我们真正想要的。
所以,问题是 - 在Rhodecode中,如何添加拉取请求更改,这些更改是在创建书签之后但在创建新头之前引入的?我的第一个想法是,它更具有特定性,但Lasse V. Karlsen(见下面的讨论)指出,这很可能是特定于RhodeCode的问题。