Re: git-svn with svn.pushmergeinfo incorrectly creates self-referencing svn:mergeinfo properties

>
> Hello,
>
> I'm using git-svn from git 1.7.8.msysgit.0 with svn.pushmergeinfo set.
> So far, it works beautifully and really closes the gap for developers
> to be able to work with git-svn, including merging/reintegrating SVN
> branches.
> However, there seem to be a subtle bug in git-svn's behavior, where
> the svn:mergeinfo property on a branch references commits from the
> same branch, effectively saying "this branch was merged onto itself".
> SVN then gets confused at this in subtle ways which ultimately cause
> it to fail.
>
> The following workflow reproduces the issue:
>
> 1. Work on some branch (git checkout my-branch)
> 2. Merge trunk into your branch (git merge trunk && git svn dcommit)
> 3. Reintegrate the branch back to trunk (git checkout master && git
> merge my-branch && git svn dcommit)
> 4. Someone else reintegrates a different branch into trunk using a
> regular SVN client (non-git).
> 5. A third someone merges trunk into their branch using a regular SVN
> client.
> 6. That third someone now tries to merge trunk into their branch
> again, using SVN.
>
> What we noticed happens is the following:
> * Step #2 adds svn:mergeinfo on your branch to represent the commits
> merged in from trunk (this is normal and desired).
> * Step #3 copies these references from the svn:mergeinfo on the merged
> branch back into the svn:mergeinfo property on trunk, so we end up
> with trunk's mergeinfo referencing its own commits (this is the buggy
> behavior -- when reintegrating with SVN, this part doesn't happen).
> * In step #4, SVN detects the self-referencing mergeinfo property on
> trunk and removes it, leaving only mergeinfo for the other branches
> (this is also desirable behavior on SVN's part, since a branch
> shouldn't include any mergeinfo references to itself).
> * In step #5, SVN tries to apply the changes made on trunk to the
> target branch, including the previous merge which removed some
> mergeinfo references. This removes the same trunk commits from the
> mergeinfo property on the target branch, leaving "holes" in mergeinfo
> property for trunk on that branch.
> * In step #6, SVN detects that the mergeinfo property for trunk on the
> target branch has holes in it, and tries to merge those revisions from
> trunk again. This causes tree conflicts and other noise which fails
> the merge.
>
> As I see it, the bug here is the creation of self-referencing
> mergeinfo properties in step #3; SVN doesn't exhibit this behavior and
> this is what causes the problems later on.
> I think a general solution is to never add an svn:mergeinfo line
> referencing the branch being dcommitted into.
>
> Can anyone confirm this is indeed a bug, suggest a fix or workaround
> and/or point me at the relevant code?
>
> Thank you,
>
> Avish