Re: Migrating a git repository to subversion

["Avery Pennarun" <apenwarr@xxxxxxxxx>]

On 5/15/08, Alf Mikula <amikula@xxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html