1

所以，假设我有一个实现了一些功能的书签，所以日志（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 的书签。这是提交表格，让您了解我在说什么：

在此处输入图像描述

在这种情况下，将有一个基于变更集 int 功能的拉取请求 (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 的尝试最终会在拉取请求中包含所有三个提交。这不是我们真正想要的。

所以，问题是 - 在 Rhodecode 中，如何添加在创建书签之后但在创建新头之前引入的拉取请求更改？我的第一个想法是它更具体，但 Lasse V. Karlsen（参见下面的讨论）指出这很可能是 RhodeCode 特定的问题。

4

0 回答 0