在"git svn clone"之后，我仍然没有出色的分支合并提交吗? [英] After "git svn clone", I still don't have fantastic branch-merging commit?

问题描述

完成 git svn克隆--stdlayout ... 之后，一切看起来都很好，并且我已经转换了远程分支.但是，当 git log --graph 时，我看不到任何分支合并图.正常吗?

After I did the git svn clone --stdlayout ..., everything looks good and I have converted remote branches. But when git log --graph, I don't see any branch merging graph. Is it normal?

推荐答案

自2008年夏季发布的1.5.0版本以来，Subversion支持合并跟踪. Subversion通过在合并目标上设置 svn:mergeinfo 属性来保留有关执行合并的信息，该属性可以是分支目录(例如 ^/trunk/)，也可以是任何其他目录.

Since version 1.5.0 released in summer of 2008 Subversion does support merge-tracking. Subversion keeps information on performed merges as svn:mergeinfo property set on merge target, be it a branch directory, like ^/trunk/, or any other directory.

Git和Subversion中的合并跟踪机制之间存在主要差异:

There are major differences between merge-tracking mechanisms in Git and Subversion:

1. 整个分支合并.

1. The whole branch merge.

在 master 分支上时，命令

$ git merge some-branch

生成合并提交，其第一个父级设置为 master 引用的提交，第二个父级设置为 some-branch 引用的提交(我不请在此考虑快进和冲突合并).

results in a merge commit with its first parent set to the commit referenced by master and the second parent set to the commit referenced by some-branch (I don't take into account fast-forward and conflicted merges here).

对于git而言，这意味着创建的合并提交包括 master 和 some-branch 的整个历史记录.

For git it means that created merge commit includes the whole history of both master and some-branch.

在您将 ^/trunk/分支签出到svn工作副本后，然后运行

When you've checked out ^/trunk/ branch into svn working copy and then run

$ svn merge ^/branches/some-branch trunk-working-copy

Subversion将在trunk-working-copy目录上设置 svn:mergeinfo 属性，如下所示:

Subversion will set svn:mergeinfo property on trunk-working-copy directory as follows:

/branches/some-branch:10-20,30-40,50-60

范围 10-20,30-40,50-60 包括尚未从 ^/合并到 ^/trunk/分支中的那些修订branch/some-branch/(Subversion自动检测到它们).

The range 10-20,30-40,50-60 includes those revisions which are not yet merged into ^/trunk/ branch from ^/branches/some-branch/ (Subversion detects them automatically).

Mergeinfo属性仅指定曾经合并到分支中的那些修订.用户可以检查所有这些合并的修订版本是否包含分支的整个历史记录.

Mergeinfo property just specifies those revisions which were once merged into the branch. And it's up to user to check whether all these merged revisions include the whole history of the branch.

樱桃选择合并.

当您需要将单个提交中的更改合并到您的 master 分支中时，请运行

When you need to merge changes from a single commit into your master branch, you run

$ git cherry-pick bc347a8

之后，git创建一个具有相应更改的提交，并为先前由 master 分支引用的提交设置了一个父级.

After that git creates a commit with corresponding changes and a single parent set to the commit previously referenced by master branch.

也就是说，git不会为Cherry-pick创建任何类型的合并提交.因此，git无法通过其图结构来跟踪经过精心挑选的提交.

That is, git doesn't create any kind of merge commit for cherry-pick. So, git has no means to track cherry-picked commits via its graph structure.

与之相反，Subversion会通过针对樱桃挑选的修订版调整 svn:mergeinfo 属性来跟踪樱桃挑选的合并:

Opposite to that Subversion does track cherry-pick merges by adjusting svn:mergeinfo property with respect to cherry-picked revision:

$ svn merge -c100 ^/branches/some-branch trunk-working-copy

此命令非常简单，它会如下调整 svn:mergeinfo :

This command is quite straight-forward, it adjusts svn:mergeinfo as follows:

/branches/some-branch:100

这意味着Subversion跟踪樱桃-拾取"合并.

That means Subversion tracks cherry-pick merges.

因此，翻译后您不会获得合并提交.据我所知，git-svn在合并历史记录时会遇到某些问题.

So, you don't get merge commits after the translation. To my best knowledge git-svn has certain problems when it comes to merge history.

但是作为subgit开发人员，我不得不说subgit应该正确处理合并跟踪信息.在分支机构上设置的 svn:mergeinfo 属性很可能不包括合并到它们的分支机构的整个历史记录.这是可能发生的情况:

But as subgit developer I have to say that subgit should correctly handle the merge-tracking info. Most probably svn:mergeinfo property set on your branches doesn't include the whole history of the branches merged to them. Here's how that could happen:

• 您使用的是旧的svn客户端(<1.5)，因此您的分支机构没有足够的合并跟踪信息.
• 您已经执行了点点滴答，并从添加到 svn:mergeinfo 中跳过了一些修订范围.
• 您在不是分支目录的目录上设置了 svn:mergeinfo ，即它们不是 ^/trunk/， ^/branches/some-branch 等(用于标准布局).

• You have used old svn client (< 1.5), so your branches don't have enough merge-tracking information.
• You have performed cherry-picks and skipped some revision ranges from adding into svn:mergeinfo.
• You have svn:mergeinfo set on directories which are not branch directories, i.e. they are not ^/trunk/, ^/branches/some-branch, etc (for standard layout).

要解决此问题，您必须找到合并跟踪信息的跳过部分并将其添加到分支中:

To fix that you have to find the skipped part of merge-tracking information and add it into your branches:

1. 尝试查找尚未合并的修订版本:

1. Try to find which revision are not yet merged:

$ svn mergeinfo --show-revs eligible ^/branches/some-branch/@HEAD ^/trunk/@HEAD

输出必须包含您尚未从 ^/branches/some-branch/合并到 ^/trunk/的所有修订.

The output must include all the revision you haven't yet merged from ^/branches/some-branch/ to ^/trunk/.

尝试通过svn合并尚未合并的修订.

Try to merge not yet merged revisions by svn.

• 如果您认为所有更改都已合并，请使用svn merge命令的--record-only选项；
• 如果不确定，最好执行正常的svn合并，以应用所有丢失的更改.

作为一项不错的奖励，您可以参考与合并跟踪相关的 SubGit规范东西，上面我已经说了一些漂亮的图表.

As a nice bonus you may refer to SubGit specification related to the merge-tracking stuff, it has some pretty diagrams for all I've said above.

这篇关于在"git svn clone"之后，我仍然没有出色的分支合并提交吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！