Git：无法从 HEAD 历史记录确定上游 SVN 信息
我已经成功使用 git-svn 连接到我的 svn trunk 一段时间了。我最初通过这样做来设置我的存储库：
git svn clone -s http://domain.com/svn/name-of-repo
我已经设置了相当长一段时间（可能接近一年）并且没有遇到问题，很可能是因为我所做的一切都在本地 git 分支上，我最终合并了回到我的主分支，并提交回 svn 主干。
最近，我需要开始向同一个 svn 存储库中的另一个分支提交一些更改， http://domain.com/svn/name-of-repo/branches/demo。
我可以通过编辑 .git/config 文件并添加这些行来从该分支获取一次：
[svn-remote "svndemo"]
url = http://domain.com/svn/name-of-repo/branches/demo
commiturl = http://domain.com/svn/name-of-repo/branches/demo
fetch = :refs/remotes/git-svn-demo
然后我运行以下命令来获取演示分支，从修订版 4034 开始：
git svn fetch svndemo -r 4034
所以现在我有一个名为remotes/的新远程分支git-svn-演示。从那里我创建了一个功能分支：
git checkout -b svndemo-local remotes/git-svn-demo
它抓住了我需要的东西，所以我做了我必须做的更改，提交到我的本地分支，然后尝试运行“git svn fetch && git svn rebase”。两者都返回错误：
无法从工作树历史记录中确定上游 SVN 信息
这就是我陷入困境的地方。我环顾过SO和其他网站（Google），但除了“git-svn再次克隆存储库，然后重新开始”之外没有找到解决方案，这并不理想。
我查看了我的 .git/svn/refs/remotes/git-svn-demo/unhandled.log 并将其与我的 .git/svn/refs/remotes/trunk/unhandled.log 进行了比较，没有什么明显不同他们。
我还查看了来自该远程分支的初始获取的提交消息，其中包含 git-svn-id 信息。
blah blah blah，这是提交消息，blah blah blah
git-svn-id：http://domain.com/ svn/name-of-repo/branches/demo@4034 e6edf6fb-f266-4316-afb4-e53d95876a76
我很想听到关于这个的新想法。
I've been successfully using git-svn to connect to my svn trunk for some time. I initially setup my repo by doing this:
git svn clone -s http://domain.com/svn/name-of-repo
I've had this setup for quite a while (maybe close to a year) and hadn't had problems, most likely because everything I do is on a local git branch, that I eventually merge back into my master branch, and commit back to the svn trunk.
Recently, I've needed to start committing some changes to another branch in the same svn repo, http://domain.com/svn/name-of-repo/branches/demo.
I was able to fetch from that branch once by editing my .git/config file and adding these lines:
[svn-remote "svndemo"]
url = http://domain.com/svn/name-of-repo/branches/demo
commiturl = http://domain.com/svn/name-of-repo/branches/demo
fetch = :refs/remotes/git-svn-demo
Then I ran the following command to grab the demo branch, starting at revision 4034:
git svn fetch svndemo -r 4034
So now I have a new remote branch called remotes/git-svn-demo. From that I created a feature branch:
git checkout -b svndemo-local remotes/git-svn-demo
That grabbed what I needed, so I made the changes I had to make, committed to my local branch, then tried to run "git svn fetch && git svn rebase". Both returned errors:
Unable to determine upstream SVN information from working tree history
And that is where I am stuck. I've looked around SO, and other sites (Google) but hadn't found a solution aside from "git-svn clone the repo again, and start over" which isn't ideal.
I've looked at my .git/svn/refs/remotes/git-svn-demo/unhandled.log and compared it to my .git/svn/refs/remotes/trunk/unhandled.log, and there's nothing significantly different about them.
I also looked at the commit message that came down from the initial fetch of this remote branch, and it include the git-svn-id information in it.
blah blah blah, this is the commit message, blah blah blah
git-svn-id: http://domain.com/svn/name-of-repo/branches/demo@4034 e6edf6fb-f266-4316-afb4-e53d95876a76
I'd love to hear a fresh idea on this one.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
要访问 svn 分支，您不需要添加新的 svn 远程服务器。当您使用 -s （标准）选项设置 git svn 克隆时，git 还会跟踪分支下定义的所有分支。
您应该能够使用 gitbranch -r 看到这些分支（在本例中为分支演示）。
如果你检查了它，你可以在其中工作并 svn dcommit 到它。
我不确定更改 svn-remote 是否弄乱了您的存储库，但我在您的位置上，我会假设它确实弄乱了，并且会以您原来的克隆命令重新开始。
To access svn branches you don't need to add a new svn remote. When you have set up your git svn clone using the -s (standard) option git also tracked all the branches defined under branches.
You should be able to see those branches with
git branch -r(in this case the branch demo).If you check it out you can work in it and svn dcommit to it.
I'm not sure if changing the svn-remote has messed up your repository or not, but I in your place I would assume that it did and would start over with your original clone command.