What is the best way to clone branches after cloning only the trunk in git-svn?

Question

Given a large Subversion repository with many branches, I want to start using git-svn by cloning trunk first and adding specific branches later. I have seen at least three ways to do this, but are any of them “officially” or is there a better way?

Assume the following location:

 https://svn-repo.com/svn/company +--core | +--trunk | +--branches | | +--fastboot | | +--playground | +-tags +--mobile +--trunk +--branches +--tags 

So, to clone only that part (without branches) of the revision 12345 of the core project:

 $ git svn clone --username=svnuser -r 12345 -Ttrunk https://svn-repo.com/svn/company/core 

This will clone the core project into a directory with the same name, and running git svn rebase will change all changes (after version 12345). At this point .git/config should be something like this in it:

 [svn-remote "svn"] url = https://svn-repo.com/svn/company fetch = core/trunk:refs/remotes/trunk 

So far so good. Now let's say I want to add a playground branch. Here it gets a little foggy.

---

Option 1 : update the existing remote in .git/config by adding a branch there:

 [svn-remote "svn"] url = https://svn-repo.com/svn/company fetch = core/trunk:refs/remotes/trunk branches = core/branches/{playground}:refs/remotes/branches/* 

At this point I was able to:

• Pull in the revision 23456 branches of the playground

  $ git svn fetch -r 23456

• Create a local branch and switch to it

  $ git checkout -b playground branches/playground

• Check out the latest changes:

  $ git svn rebase

---

Option 2 : add a new remote in .git/config (in addition to the existing one):

 [svn-remote "playground"] url = https://svn-repo.com/svn/company fetch = core/branches/playground:refs/remotes/playground 

Here the steps are similar to the steps from Option 1 :

 $ git svn fetch playground -r 23456 $ git checkout -b playground remotes/playground $ git svn rebase 

---

Option 3 I also saw someone adding a new selection to an existing remote:

 [svn-remote "svn"] url = https://svn-repo.com/svn/company fetch = core/trunk:refs/remotes/trunk fetch = core/branches/playground:refs/remotes/branches/playground 

I'm not quite sure if this is correct or if it will even work. I can not find where I saw it.

---

I currently adhere to Option 1 , but I would really like to know the most suitable way to do this.

Answer 1

All the options you check are valid and there is no “canonical” way to do this, in part because (from the point of view of git svn ) there is not a single canonical way to host the Subversion repository.

Options 1 and 3 that you have chosen are essentially equivalent. Personally, I would go with option 3, but the result would be identical to your option 1.

Option 2 will work, but this will prevent Git from detecting a commit history that crosses branches - Git usually tries to detect that Subversion commits that merging or creating branches, and writing them as such to Git, does, but it cannot do this if viewed two branches as completely separate repositories.

However, adding new branches at a later date, you lose a lot of history. Consider the following thread:

• The Git repository contains only git svn trunk samples.
• Someone creates a branch of the playing field from the chest, commits some commits in this branch, then combines the playing field with the trunk.
• You use git svn to extract the trunk; he sees the merge, but knows nothing about the branch of the playground, adds it to the Git repository as a regular commit.

If you were to collect the branch of the playing field all the time, Git would detect the branch and merge and write them down as such. Adding a branch to the playground subsequently will not help unless you use git svn reset to reselect all commits, because git svn will not rewrite old commits to mark a merge.

What I did was immediately clone all the branches, as suggested by Chronial in the comments. This is a slow process (I did it with a Subversion repository of 100,000 with almost 300 branches and tags), which can take several days, but you can just leave it in the background and when this is done you will have a full Subversion history.