Hg:如何像git的rebase那样做一个rebase

Question

在Git我可以这样做:

1. Start working on new feature:
$ git co -b newfeature-123  # (a local feature development branch)
do a few commits (M, N, O)

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

2. Pull new changes from upstream master:
$ git pull
(master updated with ff-commits)

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

3. Rebase off master so that my new feature 
can be developed against the latest upstream changes:
(from newfeature-123)
$ git rebase master

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

我想知道如何在Mercurial中做同样的事情,我已经在网上搜索了答案,但我能找到的最好的是:git rebase - 可以做到这一点

该链接提供了两个示例:
1.我将承认:(将示例中的修订替换为我自己的示例中的修订)

hg up -C F  
hg branch -f newfeature-123  
hg transplant -a -b newfeature-123 

并不是太糟糕,除了它作为一个未合并的头留下了预先重组的MNO并创建了3个新的提交M',N',O'代表它们从更新的主线分支出来.

基本上问题是我最终得到这个:

master 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 up F
hg branch newfeature-123
hg qpush -a
hg qdel -r qbase:qtip

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

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

但是这些命令(全部6个!)看起来要复杂得多

$ git rebase master

我想知道这是否是Hg中唯一的等价物,或者是否有其他方法可以像Git一样简单.

Answer 1

VonC有你想要的答案,Rebase扩展.然而,值得花一两秒时间考虑为什么默认情况下mq和rebase都不会被启用:因为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并查看它们最初编码的内容以及我在整个工作中对主线的变化的反应.不是每个人都认为它有价值,但我坚信,源代码控制的工作不是向我们展示我们希望发生的事情,而是实际发生的事情 - 每一个deadend和每个重构都应该留下不可磨灭的痕迹,并且重新定位和其他历史编辑技术隐藏.

现在,在我把肥皂盒拿走的时候去挑选VonC的答案.:)

Answer 2

您可能正在寻找Rebase Extension.(作为SummerOfCode 2008的一部分实施)

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

来自:

至:

如下面的步骤评论:

如果您没有提取更改,并且您的仓库中有两个分支,则可以执行(使用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

Answer 3

假设你有一个现代的Hg安装,你可以简单地添加:

[extensions]
rebase = 

到〜/ .hgrc.

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

Answer 4

我不认为上面的答案达到了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行为.后来有几个别名,我像任何人的业务一样反对.