<p>we are using git-svn to manage branches of an SVN repo. We are facing the following problem: after a number of commits by user X in the branch, user Y would like to use git-svn to merge the changes in branch to trunk. The problem we're seeing is that the commit messages for all the individual merge operations look as if they were made by user Y, whereas the actual change in branch was made by user X.</p>

<p>Is there a way to indicate to git-svn that when merging, use the original commit message/author for a given change rather than the person doing the merge?</p>

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.