Thread (1 message) 1 message, 1 author, 2016-06-15

Re: [PATCH 2/2] git-svn: handle SVN merges from revisions past the tip of the branch

From: Toby Allsopp <hidden>
Date: 2016-06-15 22:47:43

On Fri, Nov 13 2009, Sam Vilain wrote:
Toby Allsopp wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help