Sam Vilain wrote: >>> I'd say 'git-svn merge' as a wrapper for 'git merge --no-ff' would be cleaner. >>> >> That unfortunately does not solve the problem. >> > > I think we 'just' need to fix pushing merges back to SVN - so that they > properly set Subversion 1.5+ (and possibly SVK) merge attributes - and > if it is ambiguous which branch to push to, force the user to decide. > Whoops, I missed the thrust of the current issue; it won't be ambiguous, it'll be unambiguously wrong, so this doesn't apply. In which case I'd guess the moral equivalent of --track would have to go forward, or a per-branch basis. I think that writing a real fast-forward merge should only happen on dcommit, not git merge, because that is what is required for SVN. Ideally, it should also have the property that it doesn't cycle; null merges between two branches should not carry on indefinitely. Sam. - 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
