Junio C Hamano <junkio@xxxxxxx> writes: >> +if test "$Status" = "committed"; then >> + git svn dcommit || \ >> + die "Can't commit to Subversion" >> + >> + # dcommit will update our current HEAD to point to the newly committed >> + # svn revision. Update grafts file to tell git that it's a merge. >> + NewRevision="`git rev-list --max-count=1 HEAD`" >> + echo "$NewRevision $OldHead $RevToMerge" >> $GitDir/info/grafts > > This graft look very yucky, and would not scale. Style issues aside... I do not know what dcommit is supposed to do, but I wonder if that graft part can be folded into it. Even if git-svn cannot deal with merges that happen on the svn side, assuming if your grafting solution works, it indicates that git-svn itself does not have trouble seeing a merge commit on git side, as its invocation of "git-rev-list --parents" would show that the commit you grafted an extra parent to has two parents and git-svn needs to be able to deal with it. The command sequence in your contrib script is: - make a commit on top of git-svn managed head by hand, recording what should have happened if git-svn knew how to merge two svn branches; - make svn dcommit to record it to svn side, and let it make an extra commit to mark the synchronization between git-svn managed head and svn repository; - pretend that the synchronization commit svn dcommit made has an extra commit, which is what you created by hand; So perhaps you can add an option "git-svn dcommit --merge $OldHead $RevToMerge" that does whatever it usually does and record the resulting commit as a merge between these two commits? - 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