Re: Migrating a git repository to subversion

From: Avery Pennarun <apenwarr@gmail.com>
Date: May 15, 2008, 23:19 UTC
Message-ID: <32541b130805151619y7dcb3812i1440ebbb0def98ad@mail.gmail.com>
In-Reply-To: <42dc968d0805151608q2ed89fc8madcd8d341a4ed1df@mail.gmail.com>

On 5/15/08, Alf Mikula <amikula@gmail.com> wrote:

Show 6 quoted lines

>  1. Create a new, empty subversion project with trunk/tags/branches subdirs.
>  2. git svn clone http://myhost.com/path/to/project --stdlayout
>  3. git pull ../git_project
>  4. git svn dcommit
>
>  This put all my files into Subversion, but under a single commit. [...]

Step 3 created a "merge commit", which connected the (presumably, but not necessarily, empty) repository from step 2 to the other one in step 3. git-svn doesn't know how to break apart a merge into its parts (mostly because it's theoretically impossible to do in the general case :)) so it just makes a single svn commit.

The way people usually deal with this when using git-svn is they use "git rebase" to simplify their history and eliminate the need for merge commits. This makes git-svn much happier, but unfortunately makes future git merging a bit more complicated.

Anyway, to answer your question: add a new step 3.5 that's something like:

  git rebase WHATEVER

Where WHATEVER is the name of the last commit git-svn created in step 2.

Have fun,

Avery