When someone does a “cherry-pick merge” with Subversion, Subversion records the commit that was merged in the metadata for the files and folders involved.
When you do a git svn fetch, Git sees that merge metadata, and tries to interpret it as a merge between the Git remote branches. All this message means is that Git tried to do that, but failed, so it’ll record it as a regular commit rather than a merge.
It’s not something you need to worry about unless you’re seeing bugs in how Git picks up Subversion commits.
In more detail:
Say you have a Subversion repository with two branches A and B, with a matching Git svn repository:
A B
* r6
| * r5
* | r4
| * r3
|/
* r2
* r1
If you were to reintegrate branch B back into branch A, you’d use a command in a branch A working copy like svn merge -r 3:HEAD ^/branches/B or just svn merge --reintegrate ^/branches/B. Subversion would record metadata in svn:mergeinfo tags recording that this merge had taken place, and your next git svn fetch will see this metadata, see that branch B has been reintegrated into branch A, and record the corresponding commit in its history as a merge too.
If you just wanted a single commit from branch B in branch A (say r3 added a feature you need), but you don’t want to reintegrate the entire branch yet, you’d instead use a Subversion command like svn merge -c 3 ^/branches/B. Again, Subversion would record merge metadata, and Git would see this and try to work out if it could record a branch merge as in the previous example. In this case it can’t: branch A doesn’t contain anything like branch B‘s r5. That’s what triggers this warning.