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
