Hi, With the introduction of the svn.pushmergeinfo flag, merging SVN branches using git-svn has become possible and streamlined, with git svn rebase acting as the usual method to get up to date with remote changes. However, when git svn rebase is performed after an unpushed merge, the rebase operation follows both parents and replays both the user's local commits and those from the merged branch. As a concrete example, suppose I branch from master (tracking svn/trunk) to a new branch called 'topic'. I commit a few commits on topic and then merge from svn/trunk. Meanwhile someone else has also committed and dcommitted to topic, which requires me to svn rebase. Upon svn rebase, my local 'topic' branch is reset to the updated svn/topic, and then both my commits *and the ones I merged from trunk* are replayed -- essentially duplicating them. What should have happened is for the merge commit to be replayed as a merge (instead of each of its commits individually replayed on the current branch). Incidentally, this is exactly what --preserve-merges is supposed to do; however despite the git svn docs claiming that git svn rebase accepts all the options git rebase does, this particular flag is not recognized. So, at the very least, I think git svn rebase should honor the -p / --preserve-merges flag. Additionally, I propose that -p should be made the default for git svn rebase, or it should at least warn or abort when it encounters merges about to be rebased, or otherwise find a way to avoid the current behavior which is rarely the desired outcome (unless I'm missing something obvious?). Thoughts? Avish -- 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