Re: git-svn set-tree bug

> Junio C Hamano <gitster@pobox.com> wrote:
> > Eric Wong <normalperson@yhbt.net> writes:
> > 
> > > If dcommit detects a merge commit when doing rev-list When looking at
> > > commit objects, is it safe to assume that the first parent is always the
> > > "mainline" and that parents after it are the ones to merge from?
> > >
> > > So if I saw:
> > >
> > > commit $X
> > > parent $A
> > > parent $B
> > >
> > > I'd basically do:
> > >   reset --hard $A
> > >   merge --squash $B
> > >
> > > And resulting in $C which would have the same tree as $X,
> > > then, when dcommit-ting, $D would be created with two parents:
> > >   $D~1 (svn), $B (git), but not $A
> > 
> > I am not sure what you mean by "mainline", but I assume that you
> > mean "SVN is the main and we are tracking it while taking
> > advantage of more efficient and merge-capable git in guerrilla
> > fashion".  Because the tip of the current branch is what the
> > user is pushing back to SVN via dcommit, I would say it is safe
> > to assume that the first parent of such a merge is the line that
> > corresponds to the SVN branch you are keeping track.
> 
> Yes, "mainline" meaning the history that would be committed to SVN if
> history were linear.
> 
> I've gotten the following patch working for Joakim's second test script
> (with dcommit before merge).  However, without the dcommit before merge
> in the first test script, git-svn has trouble figuring out which history
> to follow.  It'll take more work to figure out what to do in this
> situation, and how to deal with more complex history...
> 
> Subject: git-svn: Allow dcommit to handle certain single-parent merge commits
> 
> This only works if a merge is the first commit to be committed
> in a chain of commits.