我可以在Mercurial压缩提交吗?

时间:2009-11-12 21:40:00

标签: mercurial

我有一对应该只是一个提交。如果我使用git,我会使用:

git rebase -i <some-commit-before>

然后压扁它们。

我能用mercurial做到吗?如果是这样,怎么样?

7 个答案:

答案 0 :(得分:85)

是的,您可以使用mercurial执行此操作而不需要Concatenating Changesets的任何扩展名。

或者,如果您想使用扩展程序,可以使用:

答案 1 :(得分:38)

我最喜欢的是hg strip --keep命令。然后我在一次提交中提交所有更改。

这对我来说是最快速,最舒适的方式,因为我喜欢在日常工作中做很多小事;)


注1:strip需要启用内置扩展程序mq 注意2:我最喜欢的Git / Mercurial客户端(SmartGit / Hg)在--keep期间默认添加strip参数。更方便的是:它提供了名为join commits的选项:]

答案 2 :(得分:31)

Rebase extension就像一个魅力。要压缩2次提交:

$ hg rebase --dest .~2 --base . --collapse

Dot是当前版本的快捷方式。

当您在分支上进行一些提交并希望将它们全部合并为一个时,它会更容易:

$ hg rebase --dest {destination branch (e.g. master)} --base . --collapse

这是如何运作的:

enter image description here

(来自http://mercurial-scm.org/wiki/RebaseExtension#Collapsing

答案 3 :(得分:12)

  

如果您正在阅读此答案,则可以忘记其他所有选项   在本答案中提到并使用evolve extension中的fold命令。

evolve是mercurial的延伸,它帮助我们拥有安全可变的历史,但它仍然是实验性的。您可以通过从repo克隆它并将其添加到.hgrc中来使用它。

[extensions]
evolve = ~/evolve/hgext/evolve.py

假设您在主目录中克隆了evolve repo。现在你很高兴。您也可以hg help fold寻找帮助。

<强> Fold Command

你告诉fold压缩/折叠未被破坏的线性提交链。折叠的作用是,它创建一个新的变更集,其中包含所有变更集的更改,并将所有这些变更标记为过时。您可以在docs处对此进行更深入的了解。

现在假设您有以下历史记录。

a -> b -> c -> d -> e -> f -> g

您希望压缩efg。你可以做到

hg up g
hg fold -r e

结果将是

a -> b -> c -> d -> h

其中h是变更集,其中包含来自所有三次提交efg的更改。

您还可以从历史记录中间折叠变更集,即不一定要选择包含小费的链。假设您要折叠bcd。你可以做到

hg up d
hg fold -r b
hg evolve --all

这将导致

a -> i -> j

其中ib的折叠变更集,cdjh的变更集相同。 Evolve user guide是必读的。

答案 4 :(得分:1)

使用Mercurial 4.8(9年后的2018年11月),您可以考虑使用新命令hg aborb(它是experimental feature before)。

请参见“ Absorbing Commit Changes in Mercurial 4.8

  

吸收扩展将在您的工作目录中进行每次更改,找出您的系列中哪些提交修改了该行,并自动将更改修改为该提交。
  如果有任何歧义(即在同一行上修改了多个提交),那么absorb将简单地忽略该更改,并将其保留在您的工作目录中以手动解决。

     

在技术层面,hg absorb查找所有未提交的更改,并尝试将每个更改的行映射到明确的先前提交。
  对于可以清晰映射的每个更改,未提交的更改将被吸收到适当的先前提交中。受操作影响的提交将自动重新设置基准。
  如果更改无法映射到明确的先前提交,则将其保留为未提交,并且用户可以使用现有工作流程(例如,使用hg histedit)。

     

hg absorb的自动重写逻辑是通过遵循以下行的历史来实现的:这与hg histeditgit rebase所采用的方法基本不同,后者倾向于依赖合并策略基于3-way merge来推导给定多个输入版本的文件的新版本。

     

此方法与hg Absorb跳过具有模糊应用程序提交的更改的事实相结合,意味着hg Absorb将永远不会遇到合并冲突!

     

现在,您可能正在考虑,如果忽略应用目标不明确的行,则该修补程序将始终使用经典的3向合并来干净地应用。从逻辑上说,这句话是正确的。但事实并非如此:hg absorb可以避免由hg histeditgit rebase -i执行的合并失败时的合并冲突。

答案 5 :(得分:0)

让我们假设您要压缩(合并)2个最新提交。

  1. 查找修订号

    hg log -G -l 3
    

    可能的输出:

    @  changeset:   156:a922d923cf6f
    |  branch:      default
    |  tag:         tip
    |  user:        naXa!
    |  date:        Thu Dec 13 15:45:58 2018 +0300
    |  summary:     commit message 3
    |
    o  changeset:   155:5feb73422486
    |  branch:      default
    |  user:        naXa!
    |  date:        Thu Dec 13 15:22:15 2018 +0300
    |  summary:     commit message 2
    |
    o  changeset:   154:2e490482bd75
    |  branch:      default
    ~  user:        naXa!
       date:        Thu Dec 13 03:28:27 2018 +0300
       summary:     commit message 1
    
  2. 软重置分支

    hg strip --keep -r 155
    
  3. 再次提交更改

    hg commit -m "new commit message"
    

注释

strip需要启用内置扩展名。使用以下内容创建/编辑~/.hgrc配置文件:

[extensions]
strip = 

答案 6 :(得分:-1)

我使用:

hg phase --draft --force -r 267
...
hg rebase --dest 282 --source 267 --collapse