{"thread":{"id":"36853","subject":"git-svn, different merge-parent selected in independent clones following SVN merge","startedAt":"2014-06-06T09:06:16Z","lastAt":"2014-06-06T09:06:16Z","messageCount":1,"participants":["Brett Randall"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"243452","messageId":"CALeEUB4k+Uc+Yr4-ronuHcG0YUcxJgy-N=mffxAF6jGMr0x9ig@mail.gmail.com","threadId":"36853","inReplyTo":null,"subject":"git-svn, different merge-parent selected in independent clones following SVN merge","fromName":"Brett Randall","fromEmail":"javabrett@gmail.com","sentAt":"2014-06-06T09:06:16Z","receivedAt":"2014-06-06T09:06:16Z","isPatch":false,"sender":{"key":"javabrett@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1103477?v=4"},"body":"Hi,\n\ngit version 1.8.3.2\n\nI've used git-svn on a few repositories for a long time. In what is a\ntestament to the consistency and stability of git-svn, despite often\nmaintaining separate git-svn clones on different machines, I've never\nonce seen a different commit-sha in independent clones for the same\nSVN revision. That is until just now. Two of three clones have the\nsame commit-sha, the third has a different sha for the same SVN\nrevision (and as expected for all subsequent commits). All of the\ntree-shas are identical. I never mix/push/pull local commits between\nthese independent clones.\n\nThe commit where the commit-sha diverged on the one clone is an SVN\ncommit that involved a branch merge. The difference in this clone is\nthat git-svn selected a different parent commit for one of the two\nparents of the merge (the other parent is the same). For that commit,\nthe two clones that agreed had:\n\ncommit de2dbe2e045f626cff8e282da1660c239b926765\ntree f57a4d8b88262e1f1cd79f98c7d2f5ae82751636\nparent f058fd2e05a2ef54c6bf056a3d2a46d17735253d\nparent e2722a1a24b490dbc8d7375b64050f1a0c010018\n\nand the one that did not had:\n\ncommit a3cfdff262b6afe8b22acd92f01554294f98c851\ntree f57a4d8b88262e1f1cd79f98c7d2f5ae82751636\nparent f058fd2e05a2ef54c6bf056a3d2a46d17735253d\nparent be09b04a3fa582ba12420e0a9b9c3233b41b600d\n\n(tree and one parent same, other parent and therefore new commit sha differ)\n\nOn investigation, I found that commit be09b0 is actually an ancestor\nof e2722a, and the parent commit of e2722a is another (SVN) merge\ncommit, with be09b0 as one of the parents.\n\nMy best guess is that this can happen when git-svn rebase-ing\ntrunk/master, when the associated branch isn't fully fetched. I often\nrun \"git svn fetch\" on these clones, which fetches all branches,\nbefore \"git svn rebase\" but there's a chance that I've occasionally\nrun \"git svn rebase\" on master (trunk) on its own, which only fetches\ntrunk.\n\nSo my questions are:\n\n1) Does that sound like the most likely way this would happen - seeing\nan SVN merge hit trunk during an git svn rebase on master, when the\nmerged branch was not completely git svn fetch-ed? And on the other\nagreeing clones, the better parent commit had already been picked-up\nas part of a git svn fetch?\n\n2) If so, is there any reasonable way to prevent this ... I guess\nmaking sure (perhaps via an alias) that svn rebases occur only via git\nsvn fetch followed by git svn rebase -l .\n\nThanks\nBrett\n"}]}