"无法确定工作树历史记录中的上游SVN信息"

Question

我正在尝试使用这里记录的GCC git镜像.

前段时间,我克隆了git存储库:

git clone git://gcc.gnu.org/git/gcc.git

添加了git-svn的东西:

git svn init -Ttrunk --prefix=origin/ svn+ssh://gcc.gnu.org/svn/gcc

然后git svn rebase和git svn dcommit等所有的工作很好.

几个月后,我在本地git分支上做了各种开发工作,并且我已经对上游SVN进行了更多更改:

1. 从git miror更新:

   $ git rebase
   

2. 确保我拥有SVN的最新版本,但它不起作用:

   $ git svn rebase -v
   Unable to determine upstream SVN information from working tree history
   

不知何故,我打破了元数据!除了上述内容之外,我认为我git svn fetch错误地在某个时刻做过,但这不应该是有害的,不是吗？

所以,我尝试从远程git镜像创建一个新的分支:

$ git branch svntrunk remotes/origin/trunk
$ git checkout svntrunk
$ git svn rebase
Unable to determine upstream SVN information from working tree history

网络搜索表明分支历史在某种程度上与SVN不同,但我已经检查过git log并且每个提交都有相应的git-svn-id,这似乎反驳了,不是吗？

所以,我尝试了一个来自git://gcc.gnu.org/git/gcc.git的新克隆,并且该存储库git svn rebase工作正常.这两个git rebase来自同一来源的两个回购怎么能有不同的历史？想必他们不能,而区别在于本地的元数据？

现在,我不想废弃我一直在工作的回购(虽然我可以),并将补丁导出到另一个回购提交失败了首先让git-svn.那么,我该如何修复呢？

Answer 1

你应该能够用移植物做到这一点.嫁接旨在用于引入遗留存储库是我的理解.它允许你手动告诉git某些ref有一个共同的父级.

正如评论中所提到的,可能有一个更简单的解决方案.如果所有其他方法都失败了,这将有效.

你可以下载当前的git repo(使用git或git-svn)并将旧的git-svn repo添加为远程.它们不相关,所以gitk看起来像这样:

我在工作中遇到了一些事件,我们有一些文件系统副本而不是svn副本,因此我的一些分支名称暗示了这一点.无论如何,希望这一切都有意义.很幸运,我碰巧拥有所有这些图像和故事.有什么机会!？可能相当不错,git-svn很容易混淆.

copied_from分支是他们从中复制的地方.graft_ref就是这里遇到的地方.他们添加了一堆文件,更改了属性,然后更改了一些文件.这有点乱.

一般的想法是获取原始源的索引,但文件内容与修改匹配.所以我们从ref分支开始,然后重置混合以获取索引.

$ git checkout graft_ref
$ git checkout -b graft_parent
$ git reset --mixed copied_from

如果两个分支在断开时没有进行更改,那么您不必担心这一步.

$ git commit -a -m "svn_branch changes made on svn_trunk filesystem copy"

现在我们需要做实际的移植.为了便于阅读,我在这里修剪了哈希.

$ git log -1 --pretty=format:%H graft_ref
631d3c84e35de98236c3d36c08d14ec92f9c62ae
$ git log -1 --pretty=format:%H graft_parent
96a4e87b554e0030035d35ca3aac23e9d71962af
$ echo "631d3... 96a4e8..." > .git/info/grafts

看看你会怎么想.现在我们只需要修改树上的更改.我的笔记因此缺失,但我认为这就是我要做的,呵呵.

$ git checkout svn_branch/master
$ git checkout -b consolidate_changes

$ git rebase master

你应该能够在任何地方推动这些变化.虽然git没有跟踪移植,但是移植的分支(svn_branch/master和friends)会再次中断.除非你再次进行移植,否则它实际上是一棵死树.对于git-svn来说,这不是什么大问题,因为您只需提交更改,然后再次将源拉下来作为干净的副本.