git-svn clone |虚假分支 [英] git-svn clone | spurious branches

问题描述

git svn clone [git svn clone]使用下面的命令将svn repo克隆到git中，并在执行后，我看到一些伪造的分支。 SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout〜/ temp

git分支-a

  *（无分支）
主
遥控器/abc-1.3.x 
 remotes / abc-1.3.x@113346 
 remotes / abc-1.3.x@541512 
遥控器/ branch_test_script 
遥控器/标签/模块-1.2 
 remotes/tags/modules-1.2@113346 
 remotes/tags/modules-1.2@516265 
 remotes / tags / release-1.1 
 remotes/tags/release-1.1@113346 
 remotes/tags/release-1.1@468862 
遥控器/后备箱
  

实际值在svn中创建的分支是abc，branch_test_script，模块和发行版。
有人可以帮助理解'abc-1.3.x@113346'，'abc-1.3.x@541512'...'release-1.1@468862'等是什么？

我们如何摆脱这些虚假分支/他们表示什么？

谢谢，

Gayathri

解决方案

tl; dr： $ b

git svn 创建这些@ - 分支，如果分支（或标签）是为子目录（或未被git-svn跟踪的另一个目录）创建的。总是会有一个具有相同名称的常规分支，但没有@后缀。 @分支仅作为分支的分支点存在。

---

注意：我提交了为此的补丁;此解释的编辑版本现在是官方 git svn 手册页的一部分，作为SVN分支处理（自Git 1.8.1开始）的新部分。

然而，在git中，分支始终是针对整个回购的，子目录分支不存在。因此， git svn 使用了一种解决方法。如果它检测到一个分支是从一个目录中复制而来的，而这个分支不是由git-svn作为分支进行跟踪的，它将创建一个新的历史记录。例如，对于r1234中将/ trunk / foo复制到/ branches / bar的子目录分支，它将创建：

• git向r1233反向提交每个SVN修订版本（注意该编号是创建分支之前的最后一个修订版本）。这些提交的树只会包含分支的子目录。因此，对于从r1233开始的每个修订，通常会有两个git提交，一个用于整个树（当git-svn处理 trunk 的历史记录时创建），而新

• 一个名为bar @ 1233（分支名称@ revision）的虚拟分支，指向从上面的r1233创建的提交。


• 来自r1234的提交，创建分支的提交。这个提交会将上面的分支作为其（仅）祖先。


• 一个名为bar的分支，指向第二次提交。 >
  
  

  通过这种方式，对于子目录分支栏，您可以在git中获得两个分支
  
  

  
  
  • bar @ 1233，表示分支创建的存储库的状态，它代表分支
  
  
  
  
  

  我不太确定为什么创建这个虚拟分支。我认为这是为了表示该分支从哪个分支中分支出来的信息，并且具有该分支的完整历史记录。
  
  

  ---

  
  
  

  请注意，可以使用标志 - no-follow-parent 关闭整个机制。在这种情况下，每个SVN分支都会生成一个git分支，只是SVN分支目录提交。每个分支将不受连接到历史的其余部分，并且将有自己的根提交，对应于分支中的第一次提交。

  
  

  I used the following command to clone svn repo into git and after executing it, i see some spurious branches.

  git svn clone [SVN repo URL] --no-metadata -A authors-transform.txt --stdlayout ~/temp

  git branch -a

  *(no branch)
    master
    remotes/abc-1.3.x
    remotes/abc-1.3.x@113346
    remotes/abc-1.3.x@541512
    remotes/branch_test_script
    remotes/tags/modules-1.2
    remotes/tags/modules-1.2@113346
    remotes/tags/modules-1.2@516265
    remotes/tags/release-1.1
    remotes/tags/release-1.1@113346
    remotes/tags/release-1.1@468862
    remotes/trunk
  

  Actual branches created in svn were abc, branch_test_script, modules and release. Can someone help in understanding what 'abc-1.3.x@113346' , 'abc-1.3.x@541512' ... 'release-1.1@468862' etc are ?

  How can we get rid of these spurious branches / what do they signify ?

  Thanks,
  Gayathri

  解决方案

  tl;dr:

  git svn creates these "@"-branches if a branch (or tag) was created for a subdirectory (or for another directory which is not tracked by git-svn). There will always also be a "regular" branch with the same name, but without the "@" suffix. The "@"-branch only exists as a branching point for the regular branch.

  ---

  Note: I submitted a patch for this; an edited version of this explanation is now part of the official git svn manpage, as a new section "HANDLING OF SVN BRANCHES" (since Git 1.8.1).

  ---

  In Subversion, branches and tags are just copies of a directory tree, so it's possible (though usually discouraged) to create a branch from a directory that is not itself a branch (or trunk). For example, by copying /trunk/foo to /branches/bar, instead of copying /trunk (a "subdirectory branch", so to speak), or by copying a directory that lies outside the trunk/tags/branches structure (which is possible in SVN).

  In git, however, a branch is always for the whole repo, subdirectory branches do not exist. git svn therefore uses a workaround. If it detects a branch that was copied from a directory that is not itself tracked as a branch by git-svn, it will create a new history. For example, for a subdirectory branch where /trunk/foo is copied to /branches/bar in r1234, it will create:

  • A new git commit for each SVN revision from r1233 on backwards (note the number is the last revision before the branch was created). The trees of these commits will only contain the subdirectory that was branched. So for each revision from r1233 backwards, there will usually be two git commits, one with the whole tree (created when git-svn processed the history of trunk), and the new ones.
  • A dummy branch called "bar@1233" (branch name@revision), which poinst to the commit created from r1233 above.
  • A commit from r1234, the commit that created the branch. This commit will have the branch above as its (only) ancestor.
  • A branch called "bar", which points to the second commit.

  In that way, for the subdirectory branch bar, you get two branches in git

  • bar@1233 , which represents the state of the repository that the branch was created from
  • bar, which represents the branch

  I'm not quite sure why this dummy branch is created. I think it is done to represent the information about which revision the branch was branched from, and to have a complete history for the branch.

  ---

  Note that this whole mechanism can be switched off by using the flag --no-follow-parent. In that case, each SVN branch will result in a git branch with just the commits from the SVN branch directory. Each branch will be unconnnected to the rest of the history, and will have its own root commit, corresponding to the first commit in the branch.

  这篇关于git-svn clone |虚假分支的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！