我正在使用 git-svn 来跟踪同一个 svn 存储库中的多个分支。通常这工作正常，但今天我做了一些重置和变基，突然我的分支不再提交到正确的远程分支：
$ git branch
* master
a
b
$ git svn dcommit -n
Committing to svn://server/repo/trunk ...
$ git checkout a
$ git svn dcommit -n
Committing to svn://server/repo/branches/a ...
$ git checkout b
$ git svn dcommit -n
Committing to svn://server/repo/branches/a ...
因此分支 b 将提交到branches/a 目录而不是branchs/b 目录。
我尝试过更改跟踪的分支：
$ git branch --set-upstream b remotes/b
以及其他事情，但唯一有效的解决方案是删除分支 b 并重新创建它：
$ git branch -D b
$ git branch b remotes/b
$ git svn dcommit -n
Committing to svn://server/repo/branches/b ...
现在我的问题是： git svn 如何确定要提交到哪个目录？以及如何修改这个目录呢？
谢谢，
乔纳斯
I'm using git-svn to track multiple branches in the same svn repository. Usually this works fine, but today I've done some resets and rebases, and suddenly my branches wouldn't dcommit to the right remote branch anymore:
$ git branch
* master
a
b
$ git svn dcommit -n
Committing to svn://server/repo/trunk ...
$ git checkout a
$ git svn dcommit -n
Committing to svn://server/repo/branches/a ...
$ git checkout b
$ git svn dcommit -n
Committing to svn://server/repo/branches/a ...
So the branch b would commit to the branches/a directory instead of the branches/b directory.
I've tried changing the branch that is tracked:
$ git branch --set-upstream b remotes/b
And other things, but the only solution that worked was to delete the branch b and recreate it:
$ git branch -D b
$ git branch b remotes/b
$ git svn dcommit -n
Committing to svn://server/repo/branches/b ...
Now my question is: how does git svn determine what directory to commit to? And how do I modify this directory?
Thanks,
Jonas
发布评论
评论（3）
您要查找的 SVN 配置位于克隆存储库的 .git/config 文件中。可以使用文本编辑器对其进行操作。下面是一个示例：
默认情况下，分支被假定为名称与名称匹配。要跟踪不匹配的分支名称，请重命名本地分支或为名称奇怪的分支添加显式配置（远程）：
此外，如果对来自多个 SVN 存储库的分支执行 Git 合并，
dcommit将（从逻辑上讲，但会让初次使用的用户感到困惑）以第一个合并提交父级的 SVN URL 为目标。 Git 文档指出“git svn dcommit 将尝试在git log --grep=^git-svn-id: --first-parent -1中指定的 SVN 提交之上提交”如果变基一个 SVN 分支与另一个分支相对立，这意味着“最新”提交（从属分支）将成为 dcommit 的目标。通常，用户希望以占主导地位的 SVN 存储库（分支）为目标。这要求用户在变基时使用
--no-ff选项，以确保最后的提交指向主导分支（新的精选提交）。其他相关的 StackOverflow 问题包括：
The SVN configuration you are looking for is in the .git/config file of your cloned repository. It can be manipulated with a text editor. Here's a sample:
The branches are assumed to match name-to-name by default. To track a mismatched branch name, either rename the local branch or add an explicit configuration (remote) for the oddly-named branch:
Additionally, if performing Git merges of branches from multiple SVN repos, the
dcommitwill (logically, but confusing to first time users) target the SVN URL of the first merge commit parent. The Git documentation states "git svn dcommit will attempt to commit on top of the SVN commit named ingit log --grep=^git-svn-id: --first-parent -1"If rebasing one SVN branch against another, this means that the "newest" commits (the subordinate branch) will be the target of the
dcommit. Frequently, the user wants to target the dominant SVN repo (branch). This requires the user to use the--no-ffoption when rebasing to ensure the last commit points to the dominant branch (new cherry-picked commits).Other relevant StackOverflow questions include:
我的 svn git 问题也类似。我的分支结构是这样分层的：
我首先遵循 git-svn 手册中的说明和示例：
https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
并使用以下方法克隆了我的主干：
然后我检查了branches/Android/ dev-shared 分支进行了更改并将它们提交到我本地的 git 分支。然后我尝试“git svn dcommit -n”来看看它在没有实际提交的情况下会做什么。
我看到它试图将我的分支提交到 svn 上的主干。
很高兴我使用了“-n”选项并避免提交到错误的地方。
经过大量研究，我发现最好的资源是：
http://www.janosgyerik.com/practical-tips-for-using-git-with-large-subversion-repositories/
它建议的解决方案是首先使用以下命令从 svn 检出新克隆：
然后手动编辑 .git\config 文件，为我想要处理的每个分支添加额外的获取条目：
然后，当我重试“git svn dcommit -n”时，它现在提交到正确的分支“branches/Android/dev-shared” ”。
My problem with svn git was similar. My branch structure was hierarchical like this:
I first followed instructions and examples in git-svn manual:
https://www.kernel.org/pub/software/scm/git/docs/git-svn.html
and cloned my trunk using:
I then checked out branches/Android/dev-shared branch made changes and commitedt them to my local git branch. I then tried "git svn dcommit -n" to see what it would do without actually committing.
I saw that it was trying to commit my branch commits to the trunk on svn.
SO glad I used the "-n" option and avoided committing to the wrong place.
After much research the best resource I found was:
http://www.janosgyerik.com/practical-tips-for-using-git-with-large-subversion-repositories/
The solution it suggested was to first checkout a new clone from svn using:
and then manually edit the .git\config file to add additional fetch entries for each of my branches I wanted to work on:
Then when I retried "git svn dcommit -n" it was now committing to the correct branch "branches/Android/dev-shared".
它确定从您签出的提交（仅跟随第一个父级）可以到达哪个 SVN 分支，并提交到该分支。永远不会超过一个，因为 git-svn 不会在其他分支之上创建分支。
您可以通过在 dcommitting 之前重新设置本地分支来修改它，以便它是您要在其上提交的 SVN 提交的后代（即您要提交的 SVN 分支的头）。
来自 https://git-scm.com/docs/git-svn：
It determines which SVN branch is reachable from the commit you've got checked out (following only first parents), and commits to that branch. There can never be more than one since git-svn doesn't create branches on top of other branches.
You can modify it by rebasing your local branch before dcommitting so that it's a descendant of the SVN commit you want to commit on top of (i.e. the head of the SVN branch you want to commit to).
From https://git-scm.com/docs/git-svn: