git-svn：重置主跟踪

git-svn: reset tracking for master

提问by Phillip B Oldham

I'm using git-svnto work with an SVN repository. My working copies have been created using git svn clone -s http://foo.bar/myprojectso that my working copy follows the default directory scheme for SVN (trunk, tags, branches).

我正在使用git-svnSVN 存储库。我的工作副本是使用创建的，git svn clone -s http://foo.bar/myproject因此我的工作副本遵循 SVN 的默认目录方案（主干、标签、分支）。

Recently I've been working on a branch which was created using git-svn branch myremotebranchand checked-out using git checkout --track -b mybranch myremotebranch. I needed to work from multiple locations, so from the branch I git-svn dcommit-ed files to the SVN repository quite regularly.

最近我一直在研究一个git-svn branch myremotebranch使用git checkout --track -b mybranch myremotebranch. 我需要在多个位置工作，因此从分支 I- git-svn dcommited 文件到 SVN 存储库非常有规律。

After finishing my changes, I switched back to the master and executed a merge, committed the merge, and tried to dcommit the successful merge to the remote trunk.

完成更改后，我切换回 master 并执行合并，提交合并，并尝试将成功的合并提交到远程主干。

It seems as though after the merge the remote tracking for the master has switched to the branch I was working on:

似乎在合并后，master 的远程跟踪切换到了我正在处理的分支：

# git checkout master
# git merge mybranch
... (successful)
# git add .
# git commit -m '...'
# git svn dcommit
Committing to http://foo.bar/myproject/branches/myremotebranch ...
#

Is there a way I can update the master so that it's following remotes/trunkas before the merge?

有没有办法可以更新主节点，使其remotes/trunk像合并之前一样跟随？

I'm using git 1.7.0.5, if that's any help.

如果有帮助的话，我正在使用 git 1.7.0.5。

It would be useful if you could also explain whythis happened, so I can avoid the problem happening again. Thanks!

如果您还可以解释发生这种情况的原因，那将很有用，这样我就可以避免再次发生问题。谢谢！

Edit:

编辑：

Here is my current .git/config:

这是我的当前.git/config：

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true
    autocrlf = false
[svn-remote "svn"]
    url = http://foo.bar/myproject
    fetch = trunk:refs/remotes/trunk
    branches = branches/*:refs/remotes/*
    tags = tags/*:refs/remotes/tags/*
[branch "mybranch"]
    remote = .
    merge = refs/remotes/myremotebranch

So it seems that the trunk is pointing to the correct place. However, switching to the branch then back to the master doesn't help; git svn dcommitin the master still tries to push to myremotebranch.

所以看起来树干指向正确的地方。然而，切换到分支然后回到主节点并没有帮助；git svn dcommit在主人仍然试图推到myremotebranch.

采纳答案by Daniel

When there are no changes on trunk, git does a fast-forward merge and simply sets the local "master" branch to the commit on your branch. Git-svn doesn't know how to commit fast-forward merges back to trunk, in fact it thinks "master" now is pointing to the svn branch.

当主干上没有更改时，git 会进行快进合并，并将本地“主”分支设置为您分支上的提交。Git-svn 不知道如何将快进合并提交回主干，实际上它认为“master”现在指向 svn 分支。

To work around this, use git merge --no-ffwhen merging. This will force git to create a merge commit, which can then be dcommitted to svn.

要解决此问题，请git merge --no-ff在合并时使用。这将强制 git 创建一个合并提交，然后可以将其提交给 svn。

回答by dyodji

If you git svn rebaseafter switching back to master and use --squash you can avoid this.

如果您git svn rebase在切换回 master 并使用 --squash 之后，您可以避免这种情况。

# git checkout master
# git svn rebase   //(<--the missing step)
# git merge --squash mybranch // (<-- doesn't commit, more like an svn merge would do)
... (successful)
# git add . 
# git commit -m '...' 
# git svn dcommit
Committing to http://foo.bar/myproject/trunk...
#

To solve the current state (i.e. your master is pointing to an SVN branch)

解决当前状态（即您的主人指向一个 SVN 分支）

You can 'switch' to another branch, delete master, 'switch' back to it and then merge again:

您可以“切换”到另一个分支，删除 master，“切换”回它，然后再次合并：

# git checkout mybranch
# git branch -D master
# git checkout -b master trunk
... continue with merge...
# git merge --squash mybranch

... you now have mybranch merged into master and ready to commitand then dcommitto trunk

......你现在有mybranch合并到主站和准备commit，然后 dcommit到trunk

回答by VonC

If you haven't made any commit on master, that means the git merge mybranchwas a fast-forward one: master HEADsimply move to mybranch HEAD.

如果您尚未对 master 进行任何提交，则意味着这git merge mybranch是一个快进：master HEAD只需移至mybranch HEAD.

That could explain why the git svn dcommitpushed your changes to the SVN mybranch.
It would:

这可以解释为什么git svn dcommit将您的更改推送到SVN mybranch.
它会：

• first update the corresponding SVN branch with the last Git mybranchcommits not yet dcommitted,
• record the merge to trunk on the SVN side
• and then it would rebase master on the Git side (nothing to do, already there).

• 首先使用mybranch尚未提交的最后一次 Git提交更新相应的 SVN 分支，
• 记录合并到SVN端的trunk
• 然后它会在 Git 端重新设置 master（无事可做，已经存在）。

I don't think master hasn't change its reference, but if you have a doubt (and your working directory is clean), you could (if master is currently checked out):

我不认为 master 没有更改其引用，但是如果您有疑问（并且您的工作目录是干净的），您可以（如果 master 当前已检出）：

git reset --hard remotes/trunk

回答by Walter Mundt

In general, you should not use git mergewith git svn, because svn, even with branches, doesn't support the kind of merge tracking that git does. When you need to merge a branch, I've had the most success (at least with recent svn) doing a plain svn checkout/merge process and then using git svn rebaseto update my git-svn repositories. This preserves svn's native merge tracking metadata, which (AFAIK) git-svnis completely ignorant of.

一般来说，你不应该使用git mergewith git svn，因为 svn，即使有分支，也不支持 git 所做的那种合并跟踪。当你需要合并一个分支时，我最成功的是（至少在最近的 svn 中）做了一个简单的 svn checkout/merge 过程，然后git svn rebase用来更新我的 git-svn 存储库。这保留了 svn 的本机合并跟踪元数据，（AFAIK）git-svn完全不知道。

I'm not totally sure what state your svn repository is in -- I would check to make sure the merge dcommit did what you wanted it to on the trunk. Even if it did, I bet if you look at the contents of the refs/heads/masterand refs/remotes/trunkfiles in your repo, you'll see that they're different at the moment. If that's the case, I would (with no local changes present) do a git-svn fetchfollowed by a git branch -f master remotes/trunk; git reset --hard masterto resync the git branch with the git-svn tracking branch. If you have local changes, you'll have to commit and do something like git rebase master^4 --onto remotes/trunk, where 4 is the number of commits you need to preserve. Alternatively, if they're all uncommitted, stash them with git stashfirst.

我不完全确定您的 svn 存储库处于什么状态——我会检查以确保合并 dcommit 在主干上完成了您想要的操作。即使是这样，我敢打赌，如果您查看repo 中refs/heads/master和refs/remotes/trunk文件的内容，您会发现它们目前有所不同。如果是这种情况，我会（不存在本地更改）执行 agit-svn fetch后跟 agit branch -f master remotes/trunk; git reset --hard master以将 git 分支与 git-svn 跟踪分支重新同步。如果您有本地更改，则必须提交并执行类似的操作git rebase master^4 --onto remotes/trunk，其中 4 是您需要保留的提交次数。或者，如果它们都未提交，git stash请先将它们藏起来。

Failing that, you can always get everything into svn and just wipe the repo and get a fresh checkout.

如果做不到这一点，您总是可以将所有内容放入 svn 中，只需擦除 repo 并重新结帐即可。

回答by user1338062

We have successfully used git merge --squashin git-svn feature branch development. The problem with git-svn is that while your local git-svn clone can store the merge information, once you dcommit to the svn repository, it is lost.

我们已经成功用于git merge --squashgit-svn特性分支开发。git-svn 的问题在于，虽然您本地的 git-svn 克隆可以存储合并信息，但是一旦您提交到 svn 存储库，它就会丢失。

So for other (git-)svn users the merge commits look just like plain commits. The squash is good for the same thing as git merge --no-ff(eg. producing a merge commit on master), but it also includes a list of the actual commits made in the branch being merged, which would otherwise be lost when dcommitting.

因此，对于其他 (git-)svn 用户，合并提交看起来就像普通提交。壁球与git merge --no-ff（例如，在 master 上生成合并提交）有同样的好处，但它还包括在被合并的分支中进行的实际提交的列表，否则在 dcommitting 时会丢失。

回答by Jean

I had the same problem, and I merged remotes/trunk back into master after which git svn info pointed back to trunk

我遇到了同样的问题，我将遥控器/主干合并回主，然后 git svn info 指向主干

I didn't have the time to actuall dcommit as I was leaving the project and my git-svn repo died with my worstation. I did trythe dcommit --dry-run and it said it would commit back to trunk.

当我要离开项目时，我没有时间进行实际的提交，而我的 git-svn 存储库因我的恶化而死亡。我确实尝试了 dcommit --dry-run，它说它会提交回主干。

I'll reproduce the setup and test when I get the time

当我有时间时，我会重现设置和测试

cheers

干杯