git-svn, different merge-parent selected in independent clones following SVN merge

Hi,

git version 1.8.3.2

I've used git-svn on a few repositories for a long time. In what is a testament to the consistency and stability of git-svn, despite often maintaining separate git-svn clones on different machines, I've never once seen a different commit-sha in independent clones for the same SVN revision. That is until just now. Two of three clones have the same commit-sha, the third has a different sha for the same SVN revision (and as expected for all subsequent commits). All of the tree-shas are identical. I never mix/push/pull local commits between these independent clones.

The commit where the commit-sha diverged on the one clone is an SVN commit that involved a branch merge. The difference in this clone is that git-svn selected a different parent commit for one of the two parents of the merge (the other parent is the same). For that commit, the two clones that agreed had:

commit de2dbe2e045f626cff8e282da1660c239b926765 tree f57a4d8b88262e1f1cd79f98c7d2f5ae82751636 parent f058fd2e05a2ef54c6bf056a3d2a46d17735253d parent e2722a1a24b490dbc8d7375b64050f1a0c010018

and the one that did not had:

commit a3cfdff262b6afe8b22acd92f01554294f98c851 tree f57a4d8b88262e1f1cd79f98c7d2f5ae82751636 parent f058fd2e05a2ef54c6bf056a3d2a46d17735253d parent be09b04a3fa582ba12420e0a9b9c3233b41b600d

(tree and one parent same, other parent and therefore new commit sha differ)

On investigation, I found that commit be09b0 is actually an ancestor of e2722a, and the parent commit of e2722a is another (SVN) merge commit, with be09b0 as one of the parents.

My best guess is that this can happen when git-svn rebase-ing trunk/master, when the associated branch isn't fully fetched. I often run "git svn fetch" on these clones, which fetches all branches, before "git svn rebase" but there's a chance that I've occasionally run "git svn rebase" on master (trunk) on its own, which only fetches trunk.

So my questions are:

1) Does that sound like the most likely way this would happen - seeing
an SVN merge hit trunk during an git svn rebase on master, when the
merged branch was not completely git svn fetch-ed? And on the other
agreeing clones, the better parent commit had already been picked-up
as part of a git svn fetch?

2) If so, is there any reasonable way to prevent this ... I guess
making sure (perhaps via an alias) that svn rebases occur only via git
svn fetch followed by git svn rebase -l .

Thanks Brett