2012-12-19 117 views
6

我有一个git svn回购。我在这里有多个发布分支。我正在准备一个新版本,并且作为其中的一部分,我想我会在前一版本中执行“git rebase”,以撤销未合并的任何更改。“git rebase <branch>”上git svn回购更改远程跟踪目的地?

所以我建立了我的枝叶......

git branch new_release remotes/svn-branches/new_release 
git branch old_release remotes/svn-branches/old_release 

然后我做底垫...

git checkout new_release 
git rebase old_release 
# watch it pull a bunch of commits 
git svn dcommit 
    Committing to https://svn.mysvn.net/repo/releases/old_release ... 

,我做了 “SVN dcommit” 我几乎crapped我的裤子后。这是在Subversion中哄我的旧版本分支!

为什么远程追踪分支因变形而改变?

我该如何解决自己陷入的局面?

编辑:好的,用于获取自己离开我相信我能做到以下几点:http://svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo

,因为只有那名对被拉到old_release的new_release分支提交了一把,我可以恢复它们单独在SVN回购上。尽管如此,我仍然对这里发生的事情感到困惑。

EDITx2:是的,这里有一些步骤来验证。

  1. 设置两个的Git分支远程跟踪,SVN分支的分支
  2. 退房一个
  3. 运行git svn info并观察URL指向正确的位置在SVN
  4. 运行git rebase <other_branch>
  5. 运行git svn info再次观察URL改为指向SVN中的其他分支位置

回答

7

看起来你在使用git-svn时犯了一个常见的错误。

在git-svn中没有“跟踪分支”这样的事情。它始终确定分支的URL,通过第一个父记录直到首次提交符合“git-svn-id:”签名的dmitmit。该签名附近的URL是提交将被推送的URL。但请注意,有一个双重检查:签名附近的URL和修订版本与.git/svn/refs目录中的数据结构进行比较,以及URL和修订版本是否与它们相矛盾(对于重新发布的提交,这是正确的,因为rebase没有触及那些结构),它不被考虑。所以旧的分支URL是第一个没有重定位的提交URL。

如果你想要纯粹的Git体验,你可以试试SubGit作为git-svn替换。自2.0以来,它允许创建一个可写的SVN仓库的纯Git镜像,同时关注同步和并发性。运行

$ subgit configure --svn-url <SVNURL> project.git 
$ #adjust projectX.git/subgit/{config,authors.txt,passwd} 
$ subgit install project.git 
$ git clone project.git project/ 

安装后,您可以将其用作普通的Git存储库。所以,你比如你运行:

$ git checkout new_release 
$ git rebase old_release 
$ git push origin new_release 
+0

subgit看起来确实很漂亮,可惜这是不可能的,我可以我们的SVN服务器上安装它,有太多人依靠它而将是可以理解的厌恶安装,当事情在很大程度上是“加工”。我应该怎么做我在git-svn中要做的事情? – ashgromnies

+1

你可以在你的机器上安装子目录并指定--svn-url ,即它具有与git-svn几乎相同的要求。 与git-svn ...我认为你可以1)签出new_release 2)确保HEAD已经在git-svn-id(即new_release的URL)提交正确的URL的消息3)通过git-svn-id:签名(例如在提交之前使用“git cherry-pick -n”命令和编辑消息)或者通过“git filter-branch”命令重新绑定和移除它们。说实话,我不确定删除git-svn-id签名是否有必要,但我最好删除它们。 –