On Wed, May 13, 2009 at 8:09 AM, Josef Wolf <jw@xxxxxxxxxxxxx> wrote: > Now here's the problem: This last dcommit does simply a reset, because > nothing has changed since the last dcommit. So a5cf3..c3ff2 are _not_ > marked as ancestors of svn-2/trunk, causing those cherries to be rebased > at the next dcommit with real changes. I find this a *bit* curious, since each dcommit should be adding the cherry-picked changes you just now picked from the opposite branch, right? If you weren't going to change anything, then you wouldn't have needed to do the cherry picks at all; you could have just done a merge -s ours in both directions in the first place. Anyway, regardless of the above, AFAIK there's no way to force svn to make an empty commit, which is a problem in this case. You can make a nonempty commit, though; I've done this in the past by just adding a newline to the end of some arbitrary file. Basically: git merge -s ours whatever echo >>Makefile git add Makefile git commit --amend git svn dcommit Silly, but it works. > Unfortunately, dcommit doesn't seem to have an option to force rebase > instead of resetting. Well, in fact it *is* rebasing, which throws away the extra commit because it thinks that commit didn't do anything. I've experienced this problem a few times in the past, but I knew what was happening and I figured my case was too rare to matter. Perhaps not. This could be considered a bug in git-svn, so I cc:'d Eric Wong, who I think is the main git-svn developer. Anyway, try the workaround above. Good luck, Avery -- 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