The git-svn man page recommends that you don't use merge. ""It is recommended that you run git-svn fetch and rebase (not pull or merge)"". Having said that, you can do what you like :-)
There are 2 issues here. First is that svn only stores the commiter, not the author of a patch as git does. So when Y commits the merges to trunk, svn only records her name, even though the patches were authored by X. This is an amazing feature of git, stunningly simple yet vital for open source projects were attributing changes to the author can avoid legal problems down the road.
Secondly, git doesn't seem to use the relatively new svn merge features. This may be a temporary thing, as git is actively developed and new features are added all the time. But for now, it doesn't use them.
I've just tried with git 1.6.0.2 and it "loses" information compared to doing the same operation with svn merge. In svn 1.5, a new feature was added to the logging and annotation methods, so that svn log -g on the trunk would output something like this for a merge:
------------------------------------------------------------------------
r5 | Y | 2008-09-24 15:17:12 +0200 (Wed, 24 Sep 2008) | 1 line
Merged release-1.0 into trunk
------------------------------------------------------------------------
r4 | X | 2008-09-24 15:16:13 +0200 (Wed, 24 Sep 2008) | 1 line
Merged via: r5
Return 1
------------------------------------------------------------------------
r3 | X | 2008-09-24 15:15:48 +0200 (Wed, 24 Sep 2008) | 2 lines
Merged via: r5
Create a branch
Here, Y commits r5, which incorporates the changes from X on the branch into the trunk. The format of the log is not really that great, but it comes into its own on svn blame -g:
2 Y int main()
2 Y {
G 4 X return 1;
2 Y }
Here assuming Y only commits to trunk, we can see that one line was editted by X (on the branch) and merged.
So, if you are using svn 1.5.2, you are possibly better of merging with the real svn client for now. Although you would lose merge info in git, it is usually clever enough not to complain.
Update: I've just tried this with git 1.7.1 to see if there has been any advances in the interim. The bad news is that merge within git still does not populate the svn:mergeinfo values, so git merge
followed by git svn dcommit
will not set svn:mergeinfo and you will lose merge information if the Subversion repository is the canonical source, which it probably is. The good news is that git svn clone
does read in svn:mergeinfo properties to construct a better merge history, so if you use svn merge
correctly (it requires merging full branches) then the git clone will look correct to git users.