【问题标题】:Recover from "hg update" with uncommitted changes使用未提交的更改从“hg update”中恢复
【发布时间】:2023-03-04 02:32:01
【问题描述】:

我在使用 Mercurial 时一直遇到以下问题,非常烦人:

  • 我正在修改 A。
  • 我有本地更改,我打算在 A 之上提交或修改,但还没有。
  • 我想去一些修订版 B,但我忘记了我有本地更改!
  • 我愿意hg update B。 Mercurial “有用”地尝试重新设置我的本地更改以应用于 B 之上。这通常会导致冲突,现在它要求我修复冲突。

但是,我不想解决冲突!我根本不希望我的本地更改应用于 B 之上。我希望他们留在 A,或者作为 A 之后的新提交,或者修改为 A,视情况而定。

有没有办法让我从这种状态中恢复过来?我知道的唯一方法是

  1. 修复 B 处的合并冲突
  2. 回到 A,再次遇到合并冲突
  3. 再次修复 A 处的合并冲突
  4. 在 A 提交我的更改并返回到 B

这是很多工作,而且毫无意义。我不应该将我的本地更改变基以应用于 B 之上,而只需再次变基以应用于 A 之上。

如果没有更好的方法从这个错误中恢复,有没有办法hg 在您有本地更改时拒绝更新?我从不想那样做——如果我愿意的话,我只需提交本地更改并将它们重新设置在 B 之上。

【问题讨论】:

    标签: version-control merge mercurial


    【解决方案1】:

    在某处更新后取回脏文件有点棘手。 “技巧”是确保您的工作副本在 first 更新后有脏文件。

    所以在你这样做之后

    hg update $SOMEWHERE
    

    并发现混乱,因为 Mercurial 开始打开合并工具,冷静地关闭合并工具然后运行

    hg resolve --unmark --all
    hg resolve --all --tool internal:local
    

    所有因您在其中进行更改而合并的文件现在看起来就像它们在您的脏工作副本中所做的那样。这包括干净合并的文件和提示您合并的文件。现在可以更新回来了:

    hg update $BACK
    hg resolve --unmark --all
    hg resolve --all --tool internal:local
    

    你现在应该回到你开始的地方。如果您在第一次更新后修改了文件,那么您在第二次解析后看到的是修改后的版本。这就是为什么您需要在第一次更新后解析文件的原因。

    【讨论】:

    • 我花了一段时间才真正再次遇到这个问题,因为我使用别名 hg update 来做 hg update -c 以避免这种情况。但是,我今天遇到了它,这种方法可以完美地解决它。非常感谢!
    【解决方案2】:

    如果您有任何未提交的更改,hg update -c 将中止更新。

    【讨论】:

    • 嗯,这不是 OP 实际要求的。它没有回答原始帖子中出现的 2 个问题中的任何一个。
    • @zerkms:“当你有本地更改时,有没有办法让 hg 拒绝更新?”不仅有而且还有粗体...
    • 哦,对不起,我把它和我最常用的-C 混淆了。确实有道理。
    【解决方案3】:

    如果没有更好的方法从这个错误中恢复,有没有办法 当您有本地更改时,让 hg 拒绝进行更新?

    将此添加到您的~/.hgrc

    [commands]
    update.check = noconflict
    

    只要不存在冲突,这仍将允许 hg update 进行未提交的更改。您也可以致电hg help config.update.check 了解其他可能的选择:

    "commands.update.check"
      Determines what level of checking 'hg update' will perform before
      moving to a destination revision. Valid values are "abort", "none",
      "linear", and "noconflict". "abort" always fails if the working
      directory has uncommitted changes. "none" performs no checking, and
      may result in a merge with uncommitted changes. "linear" allows any
      update as long as it follows a straight line in the revision history,
      and may trigger a merge with uncommitted changes. "noconflict" will
      allow any update which would not trigger a merge with uncommitted
      changes, if any are present. (default: "linear")
    

    【讨论】:

      【解决方案4】:

      也许答案是如果工作目录脏了就避免更新。 按以下方式修改 ~/.hgrc 应该会有所帮助:

      [hooks]
      preupdate = test -z "$(hg status)"
      

      【讨论】:

      • 我通过将update 别名为update -c 完成了类似的操作。
      猜你喜欢
      • 1970-01-01
      • 2011-03-15
      • 2020-05-15
      • 1970-01-01
      • 2023-03-27
      • 2013-09-30
      • 1970-01-01
      • 2011-04-28
      • 2016-08-15
      相关资源
      最近更新 更多