5

我喜欢命名分支的灵活性，但我对头部的增殖有些担忧。

即使分支关闭，它仍然会出现在头部。我对如何清理“hg head”的输出有一个想法我对大师的问题是：“我错过了什么？”

首先你可能会问，为什么我要完全隐藏一个命名分支的头部？由于各种原因：

  • 该功能是个坏主意
  • 该功能是一个好主意，尚未准备好合并到小费，但可能在几个月后
  • 该分支是旧标记版本的补丁版本

编辑： 事实证明，头部的增殖是我使用的旧版本 mercurial 的症状。关闭分支会在较新的 Mercurial 版本上隐藏分支的头部。

我的想法是有一个“死”头分支，所有这些封闭的分支头都将合并到该分支上。
死头将由变更集 0 作为父项，其唯一目的是捆绑现在不需要的杂散头。

deadhead 只有其他 deadhead 子项，它们永远不会合并回默认分支。

4

3 回答 3

7

您可以使用hg commit --close-branch将分支标记为已关闭：

http://www.selenic.com/mercurial/hg.1.html#commit

关闭的分支不会出现在hg branches或hg heads默认情况下（仅在指定-c/--closed选项时），所以我不确定您是如何看到“混乱”的？

通过合并事物，您究竟会获得什么？

于 2010-09-03T19:36:01.897 回答
1

留下死头似乎有一个缺点，后来版本的 Mercurial 没有解决这个问题。

假设你有很多封闭的分支头，只有一个非封闭的活动分支。进一步假设在稍后的某个时间点，您在非封闭头部 (rev good) 之上进行了错误提交 (rev bad)。在推送之前，您希望克隆您的存储库以删除该错误提交。这通常是一件简单的事情 -

hg clone --rev good BadRepo FixedRepo

不幸的是，这并没有拉动封闭的分支头，因为它们不是 rev good 的祖先。所有关闭的分支都不会在克隆的存储库中关闭。我用 Mercurial 2.3.1 对此进行了测试。

想法？

ps hgflow 扩展在合并之前会关闭功能并发布分支。这避免了封闭头问题。

关于克隆是一种丑陋的方法，它对我来说效果很好而且很容易。克隆用错误的提交替换存储库。克隆是本地的努力。那个坏的存储库就被丢弃了。我通常很快就会意识到我做了一个错误的承诺。

-b 选项只是通过使用分支名称而不是更改集标识符来改写 --rev 的一种方式。使用 --rev 选项确实会拉动修订版下的整个拓扑树。如果修订版是分支的头，则 --rev 克隆与 -b 克隆相同。-b 留下了我用 --rev 选项描述的相同问题。在原始存储库中关闭的分支如果保留为头，则会重新打开。

如果模式是留下封闭的头，那么它们很快就会大大超过相关头。除非你做一个完整的克隆，否则将这些闭包变成一个克隆是相当困难的。

于 2012-11-06T23:46:07.257 回答
0

我觉得我搞砸了为什么我可能会做一个部分克隆。我会更仔细地重申我对封闭头的担忧。

对于从存储库 X 到存储库 Y 的任何部分克隆，如果存储库 X 中存在一个带有闭包头的分支 B，并且该分支由于纯粹的拓扑原因包含在克隆中，则分支 B 将不会在存储库 Y 中关闭。此外，如果合并模式通常是留下闭包头，然后闭包头的数量是订单开发时间。

这对我来说是一个问题，所以我在合并之前关闭了我的分支。我使用 hgflow（http://nvie.com/posts/a-successful-git-branching-model）。可能的部分克隆是克隆开发分支，然后拉出主分支（例如，如果您希望消除死胡同）。如果功能和发布分支在最终合并后关闭，那么这些分支将在克隆中重新打开。

于 2012-11-07T21:03:15.690 回答