git version

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

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 .

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to