CODEWITHSUNDEEP
gitgit-svngit-branch
crankparty
crankparty

Reputation: 1240

git-svn clone | spurious branches

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

Upvotes: 28

Views: 7279

Answers (2)

sleske
sleske

Reputation: 83599

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.

Upvotes: 24

eckes
eckes

Reputation: 67067

I had such strangely called branches too when I cloned my SVN repo into a Git repo.

After reviewing the expected branches (in your case modules-1.2, abc-1.3.x, branch_test_script and release-1.1) I noticed that the @revisionnumberbranches are nothing else than commits in their prefixed branches.

If you want to do it manually, open gitk on branch abc-1.3.x and verify that abc-1.3.x@113346 and abc-1.3.x@541512 show up in the history of that branch. If so, you could delete the respective branch.

This could be a bit cumbersome if you have many branches or many commits to browse through.

Automatic way: ask git to do it for you:

git branch -r --contains abc-1.3.x@113346

will echo (or at least should)

abc-1.3.x
abc-1.3.x@113346
abc-1.3.x@541512

This means that you could safely delete abc-1.3.x@113346 because it's contained in abc-1.3.x:

git branch -r -d abc-1.3.x@113346

Because of the linear history of SVN, it is of course also contained it the (newer) commit 541512.

Side note:
You might have noticed that your SVN tags are not actually converted to Git tags and native Git branches. This could be achieved using svn2git to clone the SVN repo into a Git repo.

Upvotes: 6

Related Questions