Hg:如何做一个像git的rebase一样的rebase [英] Hg: How to do a rebase like git's rebase

查看:118
本文介绍了Hg:如何做一个像git的rebase一样的rebase的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在Git中,我可以这样做:

 
1.开始使用新功能:
$ git co -b newfeature -123#(本地功能开发分支)
做一些提交(M,N,O)

主A --- B --- C
\
newfeature-123 M --- N ---

2.从上游主控制器中取出新的更改:
$ git pull
(主控制器更新为ff-commits )

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

3.重新调整主人的设置,以便我的新功能
可以根据最新的上游更改进行开发:
(来自newfeature-123)
$ git rebase master

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




我想知道在Mercurial中做同样的事情,我在网上搜索了一个答案,但我能找到的最好的是: git rebase - can hg do that



该链接提供了2个示例:

1.我承认这一点:(用我自己的例子中的例子代替修订版)

 
hg up -CF
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

这不好,因为它留下了本地不需要的提交应该放弃。


  1. 来自同一链接的其他选项是

     
    hg qimport -r M:O
    hg qpop -a
    hg up F
    hg branch newfeature-123
    hg qpush -a
    hg qdel -r qbase: qtip

    ,这样做会产生所需的图形:

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

    但这些命令(全部6个!)看起来比$ / b
    $ b <$复杂得多p $ p>
    $ git rebase master

    我想知道这是Hg中唯一的等价物还是存在有些其他方式可用,就像Git一样简单。 VonC has 你正在寻找的答案,Rebase Extension。然而,值得花费一两分钟的时间思考为什么mq和rebase都不能在默认情况下启用:因为mercurial都是关于不可磨灭的变更集。当我按照你所描述的方式工作时,几乎每天都有这样的模式:

      1。开始使用新功能:
    $ hg clone mainline-repo newfeature-123
    做一些提交(M,N,O)

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

    2.从上游主线拉出新的更改:
    $ hg pull

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

    3.将master合并到我的克隆中,以便我的新功能
    可以针对最新的上游更改进行开发:
    (来自newfeature-123)
    $ hg合并F

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

    这就是所有必需的。我最终得到了一个新特性-123克隆,当我对它感到满意时,我可以轻松地将它推回主线。但最重要的是,我从未改变过历史。有人可以看看我的cset,看看他们最初编码的对象,以及我在整个工作中对主线更改的反应。并不是每个人都认为它有价值,但我坚信源控制的工作不是告诉我们发生了什么,而是实际发生了什么事 - 每个活动和每一个重构都会留下不可磨灭的痕迹,和其他历史编辑技术隐藏了这一点。



    现在当我把我的肥皂箱拿开的时候,去选择VonC的答案。 :)

    In Git I can do this:

    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
    


    I want to know how to do the same thing in Mercurial, and I've scoured the web for an answer, but the best I could find was: git rebase - can hg do that

    That link provides 2 examples:
    1. I'll admit that this: (replacing the revisions from the example with those from my own example)

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

    is not too bad, except that it leaves behind the pre-rebase M-N-O as an unmerged head and creates 3 new commits M',N',O' that represent them branching off the updated mainline.

    Basically the problem is that I end up with this:

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

    this is not good because it leaves behind local, unwanted commits that should be dropped.

    1. The other option from the same link is

    hg qimport -r M:O
    hg qpop -a
    hg up F
    hg branch newfeature-123
    hg qpush -a
    hg qdel -r qbase:qtip
    

    and this does result in the desired graph:

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

    but these commands (all 6 of them!) seem so much more complicated than

    $ git rebase master
    

    I want to know if this is the only equivalent in Hg or if there is some other way available that is simple like Git.

    解决方案

    VonC has the answer you're looking for, the Rebase Extension. It is, however, worth spending a second or two thinking about why neither mq nor rebase are enabled by default in mercurial: because mercurial is all about indelible changesets. When I work in the manner you're describing, which is nearly daily, here's the pattern I take:

    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
    

    and that's really all that's necessary. I end up with a newfeature-123 clone I can easily push back to the mainline when I'm happy with it. Most importantly, however, I never changed history. Someone can look at my csets and see what they were originally coded against and how I reacted to changes in the mainline throughout my work. Not everyone thinks that has value, but I'm a firm believer that it's the job of source control to show us not what we wished had happened, but what actually happened -- every deadend and every refactor should leave an indelible trace, and rebasing and other history editing techniques hide that.

    Now go pick VonC's answer while I put my soapbox away. :)

    这篇关于Hg:如何做一个像git的rebase一样的rebase的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆