Git-Svn dcommit会导致分支分裂 [英] Git-Svn dcommit causes branch splitting

问题描述

我遇到了git-svn dcommits问题，使得git存储库无法跟踪哪些提交是哪个。

我试图确保master分支在git中总是在SVN仓库中跟随主干。所以每当我工作时，我都在一个主题分支上。这是我的场景：

在主题分支中工作一段时间

  git checkout -b my-topic 
 git commit -mblah blah blah
  

然后我决定我想将我的分支合并到master中

$ g $ check $ $ $ $ git svn rebase＃在svn中获得任何变化
git rebase master my-topic
git merge my-topic --ff-only

直到这里，一切都很顺利。我现在已经掌握了master和my-topic的速度并指出了同样的提交，并且整个历史记录如下所示：

  A  -  B  -  C  -  master + my-topic 
  

然而， p>

  git svn dcommit 
  

我最终得到一棵看起来像这样的树（B和C是我最初对该主题进行的提交）：

   -  B  -  C  -  my-topic 
 / 
 A  -  B  -  C  -  master +遥控器/后备箱
  

好像在dcommit过程中，git会将提交提交到SVN，然后将它们重新放回到主服务器上。我认为这个问题是他们得到不同的提交者信息。 。我登录到与乌龟砰砰和SSH密钥使用svn

犯尚未推到SVN有提交者信息为Git仓库：

  Collin曲棍球< [e-mail]> 
  

提交到svn存储库的提交包含以下内容：

  chockey< chockey @ 6206317d-b652-48a9-a948-4036602fc523> 
  

有什么办法可以阻止这些分支分裂吗？我可以通过说：

  git rebase master my-topic 
  

，但我觉得这应该是不必要的。与此相关的主要问题是，一旦分支的更改被推送到SVN，git不再认为分支已被合并到任何地方。它使混乱删除旧的分支机构不再需要。

解决方案

在混帐SVN dcommit 命令的工作原理如下：

1. 查找来自SVN的最近一次提交;我们称之为 last-svn


2. 发送 last-svn..HEAD code> Subversion（放弃电子邮件）

3. 重置 HEAD 为 last-svn


4. 从SVN更新并创建相应的提交



换句话说，您发送给SVN的提交将被销毁，并从SVN更新中重新创建。这必须发生，因为来自SVN的提交与使用Git创建的提交不同：



• 它们的描述包含对SVN修订版的引用


• 他们的作者电子邮件是根据SVN用户名计算的

这就是为什么你的分支 my-topic 不同于 master 。

您可以自定义方式 git svn dcommit 使用 - authors-file 和 - authors-prog 选项。

I'm having a problem with git-svn dcommits making the git repository lose track of which commits are which.

I try to make sure that the master branch in git always follows trunk in the SVN repository. So whenever I'm working, I'm on a topic branch. Here's my scenario:

Working in a topic branch for a while

git checkout -b my-topic
git commit -m "blah blah blah"

Then I decide I'd like to merge my branch back in to master

git checkout master
git svn rebase #get any changes in svn
git rebase master my-topic
git merge my-topic --ff-only

Up until here, everything has gone well. I now have both master and my-topic up to speed and pointing at the same commit, and the entire history looks like this:

A -- B -- C - master + my-topic

However, when I do

git svn dcommit

I end up with a tree that looks like this (B and C are commits I originally made to the topic):

  -- B -- C - my-topic
 /
A -- B -- C - master + remotes/trunk

It seems like during the dcommit process, git pushes the commits up to SVN, then replays them back on top of master. The problem I think is that they get different committer information. I'm logging into svn with tortoise plink and an SSH key.

Commits in the git repository that have not been pushed to SVN have committer info as:

Collin Hockey <[e-mail]>

Commits that have been pushed to the svn repository have this though:

chockey <chockey@6206317d-b652-48a9-a948-4036602fc523>

Is there any way I can keep these branches from splitting? I can sort of fix it by saying

git rebase master my-topic

again, but I feel like that should be unnecessary. The main problem with this is that once a branch's changes are pushed to SVN, git no longer thinks that branch has been merged anywhere. It makes it confusing to delete old branches you no longer need.

解决方案

The git svn dcommit command works as follows:

1. Find the last commit coming from SVN; let's call it last-svn
2. Send the commits in the range last-svn..HEAD to Subversion (discarding the e-mail by the way)
3. Reset the HEAD to last-svn
4. Update from SVN and create the corresponding commits

In other words, the commits you send to SVN are destroyed and recreated from the update from SVN. This must happen because the commits that come from SVN are different from the ones created with Git:

• Their description contains a reference to the SVN revision
• Their author e-mail is computed from the SVN username

That's why your branch my-topic diverges from master.

You can customize the way git svn dcommit computes the author e-mail from the SVN username with the --authors-file and --authors-prog options.

这篇关于Git-Svn dcommit会导致分支分裂的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！