汞：如何做像git的rebase的rebase

在Git中，我可以这样做：

1.开始使用新功能：
$ git co -b newfeature-123＃（本地功能开发分支）
进行几次提交（M，N，O）

大师A --- B --- C
                \
newfeature-123 M --- N --- O

2.从上游主服务器获取新更改：
$ git pull
（master更新为ff-commits）

大师A --- B --- C --- D --- E --- F
                \
newfeature-123 M --- N --- O

3.调整主站的基础，以便使用新功能 
可以针对最新的上游变化进行开发：
（摘自newfeature-123）
$ git rebase master

大师A --- B --- C --- D --- E --- F
                            \
newfeature-123 M --- N --- O

我想知道如何在Mercurial中做同样的事情，并且已经在网上搜寻了答案，但是我能找到的最好的方法是：git rebase-hg可以做到这一点

该链接提供了2个示例：
1.我将承认这一点：（将示例中的修订替换为我自己示例中的修订）

hg up -CF  
汞分支-f newfeature-123  
汞移植-a -b newfeature-123 

效果还不错，只是它以未合并的头的形式保留了预基准MNO，并创建了3个新提交M'，N'，O'，代表它们从更新的主线分支。

基本上问题是我最终遇到了这个问题：

大师A --- B --- C --- D --- E --- F
                \
newfeature-123 \ M'--- N'--- O'
                  \
newfeature-123 M --- N --- O

这是不好的，因为它留下了应丢弃的本地不需要的提交。

2. 来自同一链接的另一个选项是

hg qimport -r M：O
hg qpop -a
拥抱
hg分支newfeature-123
hg qpush -a
汞qdel -r qbase：qtip

这确实产生了所需的图形：

大师A --- B --- C --- D --- E --- F
                            \
newfeature-123 M --- N --- O

但是这些命令（共6个！）似乎比它们复杂得多。

$ git rebase master

我想知道这是否是等效的汞含量，或者是否有其他类似Git的简单方法。

VonC可以为您提供答案，即Rebase Extension。但是，值得花一两秒钟的时间来思考为什么默认情况下不启用mq和rebase的原因是Mercurial：因为Mercurial都是关于不可磨灭的变更集。当我按照您描述的方式（几乎每天）工作时，这是我采取的模式：

1. Start working on a new feature:
$ hg clone mainline-repo newfeature-123
do a few commits (M, N, O)

master A---B---C
                \
newfeature-123   M---N---O

2. Pull new changes from upstream mainline:
$ hg pull

master A---B---C---D---E---F
                \
newfeature-123   M---N---O

3. merge master into my clone so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ hg merge F

master A---B---C---D---E---F
                \           \
newfeature-123   M---N---O---P

这真的是所有必要的。我最终得到一个newfeature-123克隆，当我对它感到满意时，我可以轻松地将其推回主线。但是最重​​要的是，我从未改变过历史。有人可以查看我的cset，看看它们最初是针对什么进行编码的，以及我在整个工作过程中对主线更改的反应。并非每个人都认为这有价值，但是我坚信源代码控制的工作是向我们展示不是我们希望发生的事情，而是向我们展示实际发生的事情-每个死角和每个重构都应留下不可磨灭的痕迹，并重新定基础其他历史记录编辑技术将其隐藏。

现在，当我放开肥皂盒时，请选择VonC的答案。:)

您可能正在寻找Rebase Extension。（作为SummerOfCode 2008的一部分实现）

在这些情况下，“分离”本地更改，将存储库与主流同步，然后将私有更改附加在新的远程更改之上可能很有用。此操作称为变基。

从：

至：

正如下面的评论通过steprobe：

如果您不提取更改，并且您的仓库中有两个分支，则可以使用keepbranches来做：

hg up newfeature-123 
hg rebase -d master --keepbranches

（--keepbranches：继承原始分支名称。）

Mojca提到：

我喜欢使用hg rebase --source {L1's-sha} --dest {R2's-sha}，但是我不知道可以--keepbranches在末尾添加。

正如图所示由乔纳森·布莱克：

 hg rebase -d default --keepbranches

假设您拥有现代化的汞装置，则只需添加：

[extensions]
rebase = 

到〜/ .hgrc。

然后你可以使用的命令hg rebase，hg pull --rebase或hg help rebase。

我认为上述答案并没有达到OP的目标，即维持他的任务分支，而只是根据父分支的后续点进行重新构建。

假设我从这张图开始（使用graphlog扩展名生成。对graphlog的痴迷）。

@  9a4c0eb66429 Feature 3 commit 2 tip feature3
|
| o  af630ccb4a80 default againagainagain  
| |
o |  98bdde5d2185 Feature 3 branch commit 1  feature3
|/
o  e9f850ac41da foo   

如果我在feature3分支上，并且想要再次基于再次提交重新构建它，我知道我可以运行hg rebase -d default。结果如下：

@  89dada24591e Feature 3 commit 2 tip 
|
o  77dcce88786d Feature 3 branch commit 1  
|
o  af630ccb4a80 default againagainagain  
|
o  e9f850ac41da foo  

任务完成？我不这么认为。问题是，再次再次基于feature3分支上的提交重新构建时，feature3分支被删除了。我的提交已移到默认分支，这是我一开始试图避免的事情。

在Git中，结果如下所示：

@  9a4c0eb66429 Feature 3 commit 2 tip
|
o  98bdde5d2185 Feature 3 branch commit 1 **feature3**
|
o  af630ccb4a80 default againagainagain
|
o  e9f850ac41da foo

请注意，feature3分支仍然存在，两个提交仍在Feature3分支上，并且默认情况下不可见。在不保留任务分支的情况下，我看不到这与合并在功能上有何不同。

更新：我发现了--keepbrancheshg rebase支持的标志，我很高兴地报告一切都是okey-dokey。使用hg rebase -d default --keepbranches，我完全复制了我渴望的Git行为。几个别名以后，我像其他人一样不停地打基础。

由于有些人吹嘘说他们认为保留所有内容的每个迭代都是很好的，所以我要指出，对于大型开源项目，接受充满合并和开发迭代的更改将使主线修订历史变得混乱，并使修订历史记录对于查看当前版本的实现方式不太有用。

当提交的更改被未写的人进行审核，然后才被接受时，此方法效果很好，因此，进入主线的更改通常可以调试并正常工作。然后，当您回溯到线的起点时，您会看到与之相关的所有更改，而不是该更改的一部分正在开发的中间。

的 X265贡献者页解释了如何重新提交了一组正在努力改变的，让他们准备提交到X265的项目。（包括使用TortoiseHG在单个文件中提交部分但不是全部更改，例如git gui的stage / unstage diff hunk进行提交）。

该过程是将hg更新到上游技巧，然后将所有更改未提交到工作目录中。搁置所有不属于您要提交的内容的内容，然后将其余内容分成许多适当的单独提交，并附上漂亮的提交消息。

我猜您会复制/粘贴，然后编辑您正在修改的补丁集的先前迭代中的提交消息。或者，您可以嫁接旧的提交（用git语言选择），然后逐一修改它们，以获取旧的提交消息作为编辑的起点。