On Mon, Apr 27, 2009 at 10:12:51PM +0200, Josef Wolf wrote: [ ... ] > give me the desired outputs. Now I do > > git checkout svn-first > git merge -s ours svn-second > git checkout svn-second > git merge -s ours svn-first > > to tell git that the branches are in sync. > > But now, when I try to > > git checkout svn-second > git svn rebase > > I get lots of conflicts. When I inspect the .git/rebase-apply directory > and the conflicts, it looks like "git svn rebase" tries to re-apply all > the commits from svn-first. When I omit the "git merge -s ours svn-first" > command, it does not re-apply those commits. So it looks like the > "git merge -s ours" wipes some information that git-svn needs to know > what was already merged. > > What am I missing? I thought the "ours" strategy is meant to tell git > that everything from that branch was merged, either manually or by > cherry-pick. After lots of RTFM, I get the impression, that cherry-pick is the only operation I can do to sync a git-svn branch with other (git or git-svn) branches. merge/pull should be avoided. But then, how do I mark cherry-picked commits as "already synched"? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html