From: Avery Pennarun <apenwarr@gmail.com>
Date: Thu, 15 May 2008 23:19:13 GMT
Subject: Re: Migrating a git repository to subversion
Message-ID: <32541b130805151619y7dcb3812i1440ebbb0def98ad@mail.gmail.com>
In-Reply-To: <42dc968d0805151608q2ed89fc8madcd8d341a4ed1df@mail.gmail.com>

On 5/15/08, Alf Mikula <amikula@gmail.com> wrote:
>  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