Hi,
I have just encountered a small problem with git-svn dcommit, which while not fatal, were quite worrying as it resulted in a detached head(?) for a while. This is with git-1.7.4-1.fc14.x86_64 .
What happened is that I was trying to cherry-pick from one svn branch (of commits from somebody else using genuine svn) into another svn branch and then do some fix-ups before dcommit to push into another svn branch.
When dcommit'ing, it bombed out in the middle because one of the older cherry-picks has no/empty svn commit message. So it results into this message:
------------------- A repository hook failed: 'pre-commit' hook failed with error output: Please enter a commit message which details what has changed during this commit. at /usr/libexec/git-core/git-svn line 576 -------------------
That's fair enough and obvious enough, but then at that point, the index is at the pre-bomb, and the working directory is post-bomb, I think, and neither is HEAD of my working branch. This is quite worrying - I think if I had done 'git gc --prune=now --aggressive' at this point I would have lost my work? Luckily I had a "git log" display before, so I did "git checkout -b preserving_work sha1_of_working_branch_head" to keep it.
So I did git rebase -i to edit the original commit messages to add something to them. (which arguably git-svn should do automatically? or empty messages really frowned upon? I always commit with at least a trivial message, but as I said, I was cherry-picking others' commits, whose development habits I have no control over)
After I fixed that and continue as I intended, then there is another bomb-out, when git-svn complains about a git commit message of mine (with minor edit): ------------- Running perl -pi -e 's(sometag="original")(sometag="replacement")' directory/* ------------- being empty. On hind-sight, it is probably not a good idea to have perl regular expression code within a commit message (git-svn itself being in perl), but complaining about a non-empty commit message (and seem to be a valid one, no strange utf8/chinese characters, etc) being empty seems to be a bug.
Hope this helps. BTW, git-svn is a great tool, and thanks a lot for that - I wouldn't use anything else (including the "authentic" svn client) to interact with svn repositories these days.
Hin-Tak