On Sat, Sep 15, 2007 at 04:08:31PM +0200, Lars Hjemli wrote:
> On 9/7/07, Lars Hjemli <hjemli@xxxxxxxxx> wrote:
> > On 9/7/07, Peter Baumann <waste.manager@xxxxxx> wrote:
> > > lets reset 'trunk' to its state before the merge and
> > > 'branch1' to the merge commit, before fixing the bug in 'branch1'.
> > >
> > > a-b-c-d-e trunk
> > > \ \
> > > \ -x-y m branch1
> >
> > Yeah, this would certainly not be handled correctly by dcommit using
> > --first-parent (but it could be handled by (a correct implementation
> > of) --upstream).
>
> Actually, I don't think there's any way to handle this correctly. The
> current git-svn will do the right thing except in cases like the one
> you described, and in these cases it can be _forced_ to do the right
> thing by editing the grafts file, so I'll drop the whole --upstream
> idea.
>
What do you mean by editing the graft file? Remove (the wrong) parent
from the merge commit by a graft? This will help you commit on the right
branch, but 7b02b85a66fee6b357e02f9e70dd0baa0fd24308 removes the
possibility to get the same graph back, because now git-svn really
honors the graft in its rebase phase.
So you would get something like this back:
a-b - c - d - e trunk
\
\ -x'-y'- m branch1
Notice that you've lost the merge information :-(
-Peter
-
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
