svn - 用 git-svn cherry-pick

Question

我面临着将一个主题分支的修订子集 merge 到另一个主题分支的问题。由于我使用的是 git-svn，我很好奇是否可以为此使用 cherry-picking。使用 Subversion，我会这样做:

svn merge -c A
svn merge -c B
svn merge -c C
...
svn commit ...

如果我尝试这样做会发生什么？

git checkout branch1
git cherry-pick A
git cherry-pick B
git cherry-pick C
git svn dcommit

如果我阅读 git svn 手册页，答案是“不要那样做”，但在谷歌搜索时我得到的印象是 git svn 现在在处理这类问题时做得更好。

Answer 1

git-svn 有一个与精心挑选的提交相关的严重问题:

假设你已经提交了 a1b2c3f9，它已经被提交到 svn 存储库中:

  $ git show a1b2c3f9
  commit a1b2c3f9...
  Author: Happy Dev <happyd@43fe5c0-...>
  Date:   Mon Nov 14 13:01:38 2011 +0000

  Commit message

  git-svn-id: https://host/svn/branches/some-branch@1000 43fe5c0-...

看到这个 git-svn-id 行了吗？这就是 git-svn 了解您的提交在 Subversion 存储库中的位置的方式。

现在你想挑选这个提交到你当前所在的 master 分支:

  $ git cherry-pick a1b2c3f9

如果没有 merge 冲突，git 会创建一个新的提交，例如，9f3c2b1a，这就是我们所拥有的:

  $ git show 9f3c2b1a
  commit 9f3c2b1a...
  Author: Happy Dev <happyd@43fe5c0-...>
  Date:   Mon Nov 14 13:01:39 2011 +0000

  Commit message

  git-svn-id: https://host/svn/branches/some-branch@1000 43fe5c0-...

因此，Git 创建了一个包含完全相同消息的提交。这导致了严重的问题。 git-svn 的旧版本将此类提交发送到错误的分支 — ^/branches/some-branch 而不是 ^/trunk/。

此问题已在最新版本的 Git 中修复。但是还有一个仍然存在:

git-svn 不支持 Subversion 的 merge 跟踪机制。

Subversion 跟踪执行的 cherry-picks 的 merge 信息，因此命令

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

调整 trunk-working-copy 的 svn:mergeinfo 属性如下:

  + /branches/some-branch: 1000

这样 Subversion 就知道这个特定的修订已经 merge 到 ^/trunk/ 分支中，因此它在进一步的 merge 中跳过这个更改。

当您运行 git cherry-pick 然后运行 ​​git svn dcommit 时，Subversion 存储库没有得到 svn:mergeinfo 修改。

---

这里是免责声明:
目前我不在 SmartGit 上工作但我与 SmartGit 开发人员保持密切联系。

Syntevo公司研发SmartGit — git-svn 的绝佳替代品。这个 Git 客户端解决了我上面描述的所有问题:

所以，你挑选 a1b2c3f9 提交:

  $ git cherry-pick a1b2c3f9

结果是您得到 9f3c2b1a 提交，然后将其推送到 Subversion 存储库中。 SmartGit 竭尽全力保留 merge 跟踪信息，因此 ^/trunk/ 分支对其 svn:mergeinfo 属性进行了必要的修改:

  + /branches/some-branch: 1000

您可以从 SmartGit 本身或使用 Git 命令行界面执行 Git cherry-pick。在第二种情况下，提交消息应该包含 cherry-pick 源的 git-svn-id 行。

SmartGit 是专有软件，但对于非商业用途是免费的。它有很多很棒的功能，更多信息请引用SmartGit documentation .

还有另一个有趣的项目解决了 git-svn 的某些问题 — SubGit .它基本上是用于在 Subversion 和 Git 存储库之间同步更改的服务器端解决方案。它比 git-svn 优越得多，并且没有它的问题。

作为 svn-via-git 的用户，我相信你也可能对此感兴趣。