Question

我有一个我不理解的条件的回购。 2个星期前，我标记了一个版本，以标记我可能需要回到的特定点。后来，我决定分支，并且还从另一个仓库（我最初克隆的仓库）中进行了更改。

感兴趣的原始版本是52：

changeset:   52:5044a88ba2a9
date:        Mon Jan 10 18:09:30 2011 -0500

稍后的一些提交，我分支到“MultiPartition”（我应该立即这样做，但我没想到会这样做）。

经过一些工作，我从姐妹仓库中取出更改（所有更改都不会与我在分支机构的工作发生冲突，所以这是安全的。）

以下是我现在看到的内容：

$ hg branches
MultiPartition                75:9fd803c56505
default                       72:3939850a77e2 (inactive)

我在MultiPartition工作，默认是姐妹报告的提示。

如果我看看头脑：

$ hg heads
changeset:   75:9fd803c56505
branch:      MultiPartition
tag:         tip
date:        Tue Jan 18 18:32:38 2011 -0500

changeset:   72:3939850a77e2
parent:      69:997a5b43216d
date:        Tue Jan 18 13:26:48 2011 -0500

changeset:   54:4ad1d36a79aa
date:        Thu Jan 13 19:14:57 2011 -0500

那里有第54次转发，我没有（故意）意味着要离开。

这是奇怪的地方：变更集52不在我当前的MultiPartition提示中（尽管它实际上是在我的磁盘上的源中，正如我所料）。我在底部附上了变更集的图表日志。

如果我使用 hgcontains 扩展程序，我会看到：

$ hg headscontaining 52
changeset:   75:9fd803c56505
branch:      MultiPartition
tag:         tip
date:        Tue Jan 18 18:32:38 2011 -0500

告诉我rev 52的内容（在当前分支中有我想要的新文件）应该在这个分支的尖端。但是，hg update -C MultiPartition会从我想要的目录中删除新文件。

如果我使用hgtk log并按感兴趣的目录过滤，我会看到添加文件的52更改集，但没有更新的更改集从此目录中删除任何文件。

唯一令我惊讶的是：Changeset 71是原始回购的合并。在该repo中，这些新文件不存在。该changset的日志是：

| o  changeset:   71:ba4c67a24185
|/|  branch:      MultiPartition
| |  parent:      70:2dcbf69c325d
| |  parent:      69:997a5b43216d
| |  date:        Mon Jan 17 17:55:10 2011 -0500

这是我的核心问题：

如果父母70：有我的预期，但父母69：没有，那怎么解决？
如何查看其他遗漏？有没有办法看到这种行为？
我想没有多个脑袋，但我似乎无法“合并”它们。从技术上讲，它们已经合并（我认为）。我该如何清理它？

很抱歉，如果这很复杂，但除了提供大量信息外，我不知道如何提出问题。

完整的graphlog：

o  changeset:   75:9fd803c56505
|  branch:      MultiPartition
|  tag:         tip
|  date:        Tue Jan 18 18:32:38 2011 -0500
|
o    changeset:   74:be7df4e2579c
|\   branch:      MultiPartition
| |  parent:      73:3e7ac80ab37a
| |  parent:      72:3939850a77e2
| |  date:        Tue Jan 18 18:31:24 2011 -0500
| |
| o  changeset:   73:3e7ac80ab37a
| |  branch:      MultiPartition
| |  parent:      71:ba4c67a24185
| |  date:        Tue Jan 18 18:28:51 2011 -0500
| |
o |  changeset:   72:3939850a77e2
| |  parent:      69:997a5b43216d
| |  date:        Tue Jan 18 13:26:48 2011 -0500
| |
| o  changeset:   71:ba4c67a24185
|/|  branch:      MultiPartition
| |  parent:      70:2dcbf69c325d
| |  parent:      69:997a5b43216d
| |  date:        Mon Jan 17 17:55:10 2011 -0500
| |
| o  changeset:   70:2dcbf69c325d
| |  branch:      MultiPartition
| |  parent:      66:79272b7e7c01
| |  date:        Mon Jan 17 17:42:04 2011 -0500
| |
o |  changeset:   69:997a5b43216d
| |  date:        Mon Jan 17 12:00:09 2011 -0500
| |
o |  changeset:   68:b39f8a7af0c5
| |  date:        Sun Jan 16 20:23:43 2011 -0500
| |
o |  changeset:   67:63d3b40427e0
| |  parent:      58:29029a74e351
| |  date:        Sun Jan 16 18:07:49 2011 -0500
| |
| o  changeset:   66:79272b7e7c01
| |  branch:      MultiPartition
| |  date:        Mon Jan 17 09:43:32 2011 -0500
| |
| o  changeset:   65:b33eb978d647
| |  branch:      MultiPartition
| |  date:        Mon Jan 17 09:39:54 2011 -0500
| |
| o  changeset:   64:1fdafb6d0e84
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 17:48:09 2011 -0500
| |
| o  changeset:   63:74942ab5113d
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 17:46:15 2011 -0500
| |
| o  changeset:   62:2cd5a6d9d120
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 01:55:23 2011 -0500
| |
| o  changeset:   61:acc73e7a35fc
|/|  branch:      MultiPartition
| |  parent:      60:c10e217081f0
| |  parent:      58:29029a74e351
| |  date:        Sun Jan 16 01:53:01 2011 -0500
| |
| o  changeset:   60:c10e217081f0
| |  branch:      MultiPartition
| |  date:        Sun Jan 16 01:45:16 2011 -0500
| |
| o  changeset:   59:2709b82b3ac0
| |  branch:      MultiPartition
| |  parent:      54:4ad1d36a79aa
| |  date:        Sun Jan 16 01:42:34 2011 -0500
| |
o |  changeset:   58:29029a74e351
| |  date:        Sun Jan 16 01:36:44 2011 -0500
| |
o |  changeset:   57:48840b75e37b
| |  date:        Fri Jan 14 11:04:06 2011 -0500
| |
o |  changeset:   56:dab5f0d40be9
| |  date:        Thu Jan 13 15:51:11 2011 -0500
| |
o |  changeset:   55:214ac45834fd
| |  parent:      51:7d0a1da31199
| |  date:        Wed Jan 12 16:49:00 2011 -0500
| |
| @  changeset:   54:4ad1d36a79aa
| |  date:        Thu Jan 13 19:14:57 2011 -0500
| |
| o  changeset:   53:8f06d69177d6
| |  date:        Thu Jan 13 14:02:42 2011 -0500
| |
| o  changeset:   52:5044a88ba2a9
|    date:        Mon Jan 10 18:09:30 2011 -0500
|
o

Answer 1

您实际上仍然在默认分支上有两个脑袋，而另一个在 MultiPartition 分支上，正如hg heads向您展示的那样。使用hg heads -t查看实际头部，无论分支如何。您似乎使用了graphlog扩展程序，因此请使用hg glog -r "branch(default)"来显示默认分支。

关于你的问题：

如果父母70：有我的预期，但父母69：没有，那怎么解决？

您可以在提示处hg export -r 52 >52.patch然后hg import 52.patch。这将重新应用更改。您的其中一个合并必须删除内容。

如何查看其他遗漏？有没有办法看到这种行为？

不是真的。就Mercurial而言，52是你的小费的祖先。如果在稍后的变更集中删除了更改，Mercurial并不知道。您可以hg diff两个不同的变更集并跟踪它被删除的位置（可能在合并中）。

我想没有多个脑袋，但我似乎无法“合并”它们。从技术上讲，它们已经合并（我认为）。我该如何清理它？

默认通常是您希望所有开发结束的地方。您可以合并两个默认标题，然后在 MultiPartition 上合并hg ci --closebranch，并将其合并为默认。

Answer 2

1：如果父母70：有我的预期，但是父母69：没有，那怎么解决？

我猜这些文件在61或71合并中被删除了。您可以使用“diff to second parent”选项在hgtk中进行检查。

3：我想不要有多个脑袋，但我似乎无法“合并”它们。从技术上讲，它们已经合并（我认为）。我应该如何清理它？

在默认分支上有两个匿名头（54和72，其中72是默认提示），只要MultiPartition分支未合并回默认值，它们就会保持打开状态。虽然后来在MultiPartition分支中合并，但它们仍然是默认分支的负责人，因为mercurial不会将后续分支视为分支的新负责人。这种处理的原因是您hg update branch时通常希望最新版本成为分支。

将MultiPartition合并回默认值时，可以删除两个默认头。完成MultiPartition之后，您还可以使用hg ci --close-branch关闭此分支（从技术上讲，您无法移除MultiPartition头，但是当它关闭时hg heads不会将其视为活动头。）

帮助mercurial repo问题

2 个答案: