Hg：如何做一个像git的rebase的rebase
在Git中，我可以这样做：
1.开始使用新function：
$ git co -b newfeature-123＃（本地特性开发分支）
做一些提交（M，N，O）
掌握A --- B --- C
\
newfeature-123 M --- N --- O
2.从上游主站拉取新的更改：
$ git pull
（主要使用ff-commits进行更新）
掌握A --- B --- C --- D --- E --- F
\
newfeature-123 M --- N --- O
3.closures高手，使我的新function
可以针对最新的上游变化而开发：
（来自newfeature-123）
$ git rebase master
掌握A --- B --- C --- D --- E --- F
\
newfeature-123 M --- N --- O
我想知道如何在Mercurial中做同样的事情，我已经在网上寻找答案，但我能find的最好的是： git rebase – 可以这样做
该链接提供了两个例子：
1.我承认这一点:(用我自己的例子中的例子replace例子中的修改）
高达-CF hg分支-f newfeature-123 hg移植-a -b newfeature-123
并不算太糟糕，只不过它将未转型的MNO作为一个没有合并的头部留下，并创build了3个新的提交M'，N'，O'，代表他们分支出更新的主线。
基本上问题是，我最终得到这个：
掌握A --- B --- C --- D --- E --- F
\ \ \
newfeature-123 \ M'--- N'--- O'
\
newfeature-123 M --- N --- O
这是不好的，因为它留下了本地，不必要的提交，应该放弃。
- 从同一个链接的另一个选项是
hg qimport -r M：O hg qpop -a hg up F hg分支newfeature-123 hg qpush -a hg qdel -r qbase：qtip
这确实导致了所需的graphics：
掌握A --- B --- C --- D --- E --- F
\
newfeature-123 M --- N --- O
但是这些命令（全部6个！）似乎比这复杂得多
$ git rebase master
我想知道这是否是Hg中唯一的等价物，或者是否有像Git一样简单的其他方法。
VonC有你正在寻找的答案 ，Rebase Extension。 然而，值得花费一两分钟的时间思考为什么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
而这确实是所有必要的。 我最终得到了一个新特性-123克隆，当我满意的时候，我可以很容易地把它推回主线。 但最重要的是，我从来没有改变历史 。 有人可以看看我的cset，看看他们最初编码的是什么，以及我在整个工作中对主线的变化有何反应。 不是每个人都认为它有价值，但是我坚信源控制的工作不是向我们展示我们希望发生的事情，而是实际发生的事情 – 每一个死刑和每一个重构都会留下不可磨灭的痕迹，和其他历史编辑技术隐藏的。
当我把我的肥皂箱拿走的时候，现在去selectVonC的答案。 🙂
您可能正在寻找Rebase Extension 。 （作为SummerOfCode 2008的一部分实施）
在这种情况下，“分离”本地更改可能很有用，将存储库与主stream同步，然后在新的远程更改之上附加私有更改。 这个操作被称为rebase。
从 ：
至：
假设你有一个现代的汞安装，你可以简单地添加：
[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分支上，默认情况下不可见。 没有保留任务分支，我不明白这是如何在function上不同于合并。
更新 ：我发现了hg rebase支持的--keepbranches标志，我很高兴地告诉所有的东西都是okey-dokey。 使用hg rebase -d default --keepbranches ，我完全复制了我所渴望的Git行为。 后来几个别名，我正在重新devise，没有人的业务。
由于有人曾经表示认为保持每一次迭代都是好事，所以我会指出，对于更大的开源项目，接受充满合并和开发迭代的变化将会导致主线修订历史的混乱，并使得修改历史logging对于查看当前版本如何到达那里不太有用。
当提交的更改被未被写入的人员审阅之前，这一切都可以正常工作，因此在进行主线更改之前，一般都会进行debugging并运行。 然后，当你回溯到一条线的起点时，你会看到所有的变化，而不是在变化发展过程中的某一点。
x265贡献者页面解释了如何重新提交正在处理的一组更改，以便将它们提交给x265项目。 （包括使用TortoiseHG在个别文件中进行一些但不是全部的修改，比如git gui的stage / unstage diff commit）。
这个过程是让hg更新到上游提示，然后在工作目录中取消所有未提交的更改。 将所有不属于你想要提交的内容的东西搁置，然后把其余的内容分解成多个单独的提交，并提交好的提交消息。
我想你会复制/粘贴，然后编辑你正在修改的补丁集的先前迭代的提交消息。 或者，也许你可以移植你的旧提交（用git语言挑选樱桃），然后逐一修改它们，以便将旧的提交消息作为编辑的起点。
