为什么git svn会建立新分支，我该如何解决？

Question

My team agreed to migrate from svn to git. So I created a repository xxwin then I ran something similar to this:

git svn clone --stdlayout --no-metadata --authors-file=users.txt svn://hostname/path xxwinRepository
cd xxwinRepository
git remote add origin https://bitbucket.org/xxxxx/xxwin.git
git push

It took a really long time but it seemed to work fine.

Then one developer said he had committed some more changes to svn since migrating.

Instead of restarting I thought I could just run

git svn fetch
git push

It seems to have pushed everything to new branches. Unfortunately this happened a couple of times before I realized what was happening. Now we have hundreds of branches..

For example we had a branch called v2_5_working in svn and now in git there are branches called origin/v2_5_working xxwin/origin/v2_5_working xxwin/xxwin/origin/v2_5_working

Is there some way to easily merge all these branches? In case there is a next time is there a way to make it merge as part of the git svn fetch ?

Answer 1

You used --no-metadata flag in your git svn clone command. This means that the git commits that were created do not have any link to corresponding svn commit, and git cannot know that the new commit the developer made to svn was supposed to go on top of some branch in git.

Only use --no-metadata if you plan to do a one-time conversion, not if the development continues on svn. Quoting the documentation :

This gets rid of the git-svn-id: lines at the end of every commit.

This option can only be used for one-shot imports as git svn will not be able to fetch again without metadata. Additionally, if you lose your $GIT_DIR/svn/ */.rev_map. files, git svn will not be able to rebuild them.

The git svn log command will not work on repositories using this, either. Using this conflicts with the useSvmProps option for (hopefully) obvious reasons.

This option is NOT recommended as it makes it difficult to track down old references to SVN revision numbers in existing documentation, bug reports and archives. If you plan to eventually migrate from SVN to Git and are certain about dropping SVN history, consider git-filter-branch 1 instead. filter-branch also allows reformatting of metadata for ease-of-reading and rewriting authorship info for non-"svn.authorsFile" users.