On 2008.05.15 19:19:13 -0400, Avery Pennarun wrote: > 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. In this case, "git svn rebase" handles figuring out what WHATEVER should be. That said, I'd suggest something different/bigger to show off git's power. Creating a linear history is not really impressive, especially when you go on and compare the svn and git repos afterwards. I'd create a svn repo with trunk, tags, branches like you have done, import that via git-svn. Then add a few commits to trunk, dcommit them. Then create a branch in _svn_ [1]. Use "git svn fetch" to get that into your git repo, do some commits on that branch, dcommit them, do some commits on trunk, dcommit them. Then checkout trunk, merge the other branch, and dcommit the result. Then repeat that, so you got two merges on trunk. If you then look at your history in gitk (for example), you'll see the merges just fine, while the svn history has no clue about it, except for the commit message. If you do that "live", you can also show off the history after the first merge, and show that the second merge needs no crappy -r123:154 option to figure out what exactly needs to be merged like svn does, because git actually records merges. The results on the svn side of things are the same as if you had done the merges there, and being able to compare that quite directly to how git does it is nice. Björn [1] Here's a small script that creates a branch in the svn repo (using the svn executable) from the most recent svn commit that is in your current git branch (yeah, it's rather ugly): #!/bin/sh if test "$1" = '' then echo "Usage: git-svn-branch <branch_name>" exit 127 fi CURRENT=$(git rev-list --first-parent --pretty=format:%b HEAD | grep -m1 -o 'git-svn-id: [^ ]*' | sed -e 's/git-svn-id: //') SRC=${CURRENT%@*} REV=${CURRENT#*@} URL=$(git config --get svn-remote.svn.url) URL=$(echo -n "$URL" | sed -e 's!//.*@!//!') DST="$URL/$(git config --get svn-remote.svn.branches | grep -o '^[^:]*' | sed -e "s/\*/$1/")" svn cp -r "$REV" "$SRC" "$DST" -m "Create branch $1" -- 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
