为什么 Mercurial 合并变更集包含没有冲突的项目？
给定这个存储库：
A1 - A2 - A3 - A4 - A5
..您执行hg pull，它从远程存储库中提取另外两个变更集，给您两个头：
A1 - A2 - A3 - A4 - A5
\
B3 - B4
假设您执行hg merge，它会为您提供M1 合并变更集：
A1 - A2 - A3 - A4 - A5----\
\ M1
B3 - B4 --------/
所以现在 hg out 将list M1...
如果您执行 hg diff -c M1 您会看到：
- 在 B3 和 B4 中添加的文件
- 在 B3 和 B4 中修改的文件的差异，这些文件没有冲突（文件未在 A3-A5 中修改）
为什么 M1 合并变更集包含这些项目？为什么需要将此变更集推送到远程存储库？
这些更改已经存在于远程存储库中的 B3 和 B4 中。我理解为什么合并变更集将包含 A3-A5 和 B3-B4 中都有更改的文件，并导致文件的新合并版本。但我不明白为什么变更集会包含不存在冲突的项目。 M3 的推送不会重复远程存储库中已有的更改吗？
Given this repository:
A1 - A2 - A3 - A4 - A5
.. you do hg pull which pulls in two more changesets from the remote repo, giving you two heads:
A1 - A2 - A3 - A4 - A5
\
B3 - B4
Let's say you do hg merge which gets you the M1 merge changeset:
A1 - A2 - A3 - A4 - A5----\
\ M1
B3 - B4 --------/
So now an hg out will list M1...
If you do hg diff -c M1 you see:
- Files that were added in B3 and B4
- The diff for files that were modified in B3 and B4 for which there were no conflicts (files weren't modified in A3-A5)
Why does the M1 merge changeset include these items? And why would you need to push this changeset to the remote repository?
These changes are already in B3 and B4 which are in the remote repository. I understand why the merge changeset would include files which had changes in both A3-A5 and B3-B4 and resulted in a new merged version of the files. But I don't see why the changeset would include items where there aren't conflicts. Won't the push of M3 duplicate changes that are already in the remote repo?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我能想到的最简单的表达方式是 B3 和 B4 以 A2 作为其更改的基础。为了使所有内容回到 1 头而不是 2 头，合并代表一个变更集，它接受 B3 和 B4 中的所有更改并将它们应用到 A5 之上。
看起来像这样的另一个原因是当你合并 B4 时你在 A5 上。如果您曾在 B4 上进行合并，则合并将在 B4 之上显示 A3、A4 和 A5 的更改（当您调用
hg diff -c M1时，您将在 B4 上）。不，推送合并不会真正以任何您认为多余的方式重复更改。我唯一一次看到重复的更改是当有人重新设置从其他地方拉取或已经推送的更改集时。
The simplest way I can think to put it is that B3 and B4 have A2 as the base on which their changes are built. To bring everything back to 1 head instead of 2, the merge represents a changeset that takes all of the changes in B3 and B4 and applies them on top of A5.
Another part of the reason it looks like that is you were on A5 when you merged B4. If you had been on B4 and merged, the merge would show A3, A4, and A5's changes on top of B4 instead (you would be on B4 when you called
hg diff -c M1).And no, pushing the merge won't really duplicate changes in any way you'd notice as redundant. The only time I've seen duplicate changes is when somebody rebases changesets that they've pulled from elsewhere or already pushed.
diff -c仅在变更集与其第一个（左）父级（在您的情况下为 A5）之间创建差异。因此，它显示了由于远程合并而在分支上发生的所有更改。diff -conly creates a diff between the changeset and its first (left) parent (A5 in your case). Thus, it shows everything that has changed on your branch because of the merge from remote.