On Fri, Nov 13 2009, Sam Vilain wrote: > Toby Allsopp wrote: > > When recording the revisions that it has merged, SVN sets the top > > revision to be the latest revision in the repository, which is not > > necessarily a revision on the branch that is being merged from. When > > it is not on the branch, git-svn fails to add the extra parent to > > represent the merge because it relies on finding the commit on the > > branch that corresponds to the top of the SVN merge range. > > I thought, "that sounds like he's repeating himself, wait a sec..." Hmm, it makes perfect sense to me :-) Does the explanation in 1/2 make more sense? The first sentence describes what Subversion does, the second what git-svn does in response. > Thanks for contributing this. There might be other bugs too, especially > when upstream has a more complicated merge hierarchy ... apparently svn > tends to get it wrong, so checking for all commits might not work in > that case. Oh yes, SVN gets the merges wrong in an alarming number of cases, it's really shocking. I only stay sane at work because I tell myself that SVN is making the case for git for me :-) > It would be nice if "dcommit" could make these commits, too... Yes. Toby. -- 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