In recent versions of git, the configuration svn.pushmergeinfo was introduced:
config key: svn.pushmergeinfo
This option will cause git-svn to attempt to automatically populate the svn:mergeinfo property in the SVN repository when possible. Currently, this can only be done when dcommitting non-fast-forward merges where all parents but the first have already been pushed into SVN.
We're using this to have a mixed environment where some developers use SVN and some use Git-SVN. This works great when branching and merging SVN-branches in Git and then git svn dcommit-ing back to SVN, and it actually correctly populates the mergeinfo property in almost all cases. However, in specific situations it does so incorrectly.
This happens mainly when merging a branch into master (trunk), after having merged trunk into that branch (effectively, the equivalent of a SVN reintegrate).
The merge from trunk to the branch adds a mergeinfo line for trunk on that branch (as desired), but the reintegrate-merge from the branch back to trunk copies that line into trunk's mergeinfo, effectively creating a self-referencing line in trunk's mergeinfo property that points to itself. As far as I know this self-reference should never happen, and doesn't happen when using SVN alone. So, I consider this a git-svn bug (which I've reported here). This in turn creates problems down the road which affect other SVN users and corrupt the mergeinfo on future commits.
What I'm looking for is a workaround: how can I easily tell git not to copy mergeinfo lines for the branch being merged into, or alternatively how can I tell SVN to remove those self-references upon commit (or any other solution which doesn't result in a self-referencing mergeinfo line but does preserve the other qualities of automatic svn:mergeinfo creation from git).
(For clarification, I am not looking for people to quote the git manual to me or tell me that "merging with Git-SVN is dangerous and not supported". Please only answer if you can help with the issue or propose an alternative workflow. Pointers into the relevant git code would also be helpful since they might allow me to create a patch to solve this. Thanks!)