当前位置：文江博客话题详情

mercurial

强制或覆盖 Mercurial 中的合并？

发布于 2024-10-28 06:53:55 字数 121 浏览 2 评论 0 原文

当我做“hg head”时，我看到两个头。

我只想从第一个开始进行更改并完全忽略另一个。

这是 hg Push -f 的作用吗？

我怎样才能告诉 Mercurial 忽略第二个头？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

泅人 2024-11-04 06:53:55

这个技巧很好地介绍了它：

https://www. Mercurial-scm.org/wiki/TipsAndTricks#Keep_.22My.22_or_.22Their.22_files_when_doing_a_merge

如果您已更新到您想要的版本，那么您将运行：

hg --config ui.merge=internal:local merge  #keep my files

您不想要 <代码>hg push -f。

This tip covers it nicely:

https://www.mercurial-scm.org/wiki/TipsAndTricks#Keep_.22My.22_or_.22Their.22_files_when_doing_a_merge

If you're updated to the one you want then you'd run:

hg --config ui.merge=internal:local merge  #keep my files

You not want hg push -f.

回复收藏 0 原文

往日情怀 2024-11-04 06:53:55

此页面提供了三种不同的去除分支的方法，但也适用于头部。当分支时，会创建变更集有多个子项。可以使用 hgbranch 命令创建命名分支，但是可以通过将两个变更集提交到同一父级来创建未命名分支（无论是偶然还是故意）。

例如，如果我创建一个新存储库，向其中添加一个文件并提交，则该提交将是变更集 0。

hg init     # create repo
# edit file myfile.txt
hg add myfile.txt 
hg ci -m 'added myfile.txt' # creates changeset 0

然后我进行更多更改并再次提交，创建变更集 1，其父级是变更集 0。

# more edits to myfile.txt
hg ci -m 'changed myfile.txt' # creates changest 1, with parent changeset 0

现在，对于某些未知原因我返回变更集 0，对 myfile.txt 进行一些更改并提交这些更改。

hg up -C 0    # update to changeset 0
# more edits to myfile.txt
hg ci -m 'edited myfile.txt' # creates changeset 2, who's parent is also changest 0

现在我们做了一些奇怪的事情。我们回到了变更集 1 之前，并进行了不同的更改。我们在代码中回到了过去，并更改了某些内容，创建了另一个宇宙，就像 BttF 第二部分中一样！

好吧，其实不是。我们实际上刚刚创建了一个分支。然而，它是一个未命名的分支，因为我们没有使用 hgbranch 命令创建它（因此不会显示在 hg 分支中）。它还创建了一个新的head。头只是没有子项的变更集，因此任何尚未合并或关闭的分支，无论命名或未命名，都将有一个头。

这是一个人为的示例，可能不是您所做的。更常见的是，如果您在两个地点工作，并且在一个地点完成工作时忘记推，或者在另一地点再次开始工作时忘记拉。如果您在一个位置完成后不推送，那么当您在第二个位置开始工作时，您可能正在处理较旧的变更集，因此任何提交都将创建第二个头。当您忘记拉动时，也会发生类似的情况。

正如我之前所说，这会创建一个未命名的分支。但是，您可以像对待任何其他分支一样对待该分支。命令 hg updatebranch_name 只是将您更新到该分支的头部，因此对于未命名的分支，您只需使用 hg update head_revision 更新到该未命名分支的头部即可hg Heads 将为您列出头信息（如果您想了解有关每个头信息的更多信息，则使用 hg Heads -v ）。

我建议简单地关闭您不再需要的头部（上面第一个链接上的第一个选项）。这样它仍然存在，以防万一您以后可能需要它，但它不会出现在 hg head 中。为此，请运行以下命令：

hg up -C head_to_close
hg commit --close-branch -m 'Closing un-wanted head'
hg up -C head_to_keep

您必须弄清楚要关闭哪个头。 hg Heads -v 将为您提供一些有关头部的扩展信息。您还可以更新每个 hg up head_changeset 并检查代码以确定要关闭哪一个。

This page gives three different methods for getting rid of branches, but will work for heads as well. A Branch is created when a changeset has more than one child. Named branches can be created with the hg branch command, however unnamed branches can be created (either on accident or on purpose) by committing two changesets to the same parent.

For example, if I make a new repository, add a file to it, and commit, that commit will be changeset 0.

hg init     # create repo
# edit file myfile.txt
hg add myfile.txt 
hg ci -m 'added myfile.txt' # creates changeset 0

Then I make some more changes and commit again, creating changeset 1, who's parent is changeset 0.

# more edits to myfile.txt
hg ci -m 'changed myfile.txt' # creates changest 1, with parent changeset 0

Now, for some unknown reason I go back to changeset 0, make some changes to myfile.txt and commit those.

hg up -C 0    # update to changeset 0
# more edits to myfile.txt
hg ci -m 'edited myfile.txt' # creates changeset 2, who's parent is also changest 0

Now we've done something strange. We've gone back before changeset 1, and made a different change. We've gone back in time in our code and changed something creating an alternate universe like in BttF Part II!

Well ok, not really. We've really just created a branch. However it's an unnamed branch since we didn't create it with the hg branch command (and thus doesn't show up in `hg branches). It has also created a new head. Heads are just changesets with no children, so any branch, named or unnamed, that hasn't been merged or closed will have a head.

This is a contrived example and and probably not what you did. What is more common is if you work from two locations and forget to push when done at one location or pull when starting work again at another location. If you don't push when done at one location, when you start work at the 2nd location you may be working on an older changeset, and thus any commits will create a second head. A similar thing happens when you forget to pull.

As I said earlier, this creates an unnamed branch. However you can treat this branch the same as any other branch. The command hg update branch_name simply updates you to the head of that branch, so for the unnamed branch you can simply update to the head of that unnamed branch with hg update head_revision and hg heads will list the heads for you (or hg heads -v if you want more info about each head).

I would recommend simply closing the head you no longer want (the first option on the first link above). That way it's still there just in case you might need it later, but it won't show up in hg heads. To do this run the following commands:

hg up -C head_to_close
hg commit --close-branch -m 'Closing un-wanted head'
hg up -C head_to_keep

You'll have to figure out which head you want to close though. hg heads -v will give you some extended info about the heads. You can also update to each one hg up head_changeset and examine the code to figure out which one you want to close.