Re: [jgit-dev] Implement cherry-pick by merge

["Shawn O. Pearce" <spearce@xxxxxxxxxxx>]

Christian Halstrick <christian.halstrick@xxxxxxxxx> wrote:
> On Tue, Sep 21, 2010 at 16:14, Shawn Pearce (Code Review)
> <codereview-daemon@xxxxxxxxxxx> wrote:
> > cherry-pick can be implemented using merge.  :-)
> >
> > Lets say we want to cherry-pick commit C, whose parent is B, and we want to apply it on top of Q:
> >
> >  o----- B ----- C
> >   \
> >    o--o--o-- Q
> >
> > * Set the "ours" side to be Q.
> > * Set the "theirs" side to be C.
> > * Fix the merge base to be C^1, that is B.
> >
> > Where there is a B-C difference, it shows up as an edit made by "them" and is applied by the merge as a "theirs" side edit.  Where there is a B-Q
> > difference, it shows up as an edit made by "us" and shows up as an "ours" side edit.  Providing that these edits aren't conflicting, the merge will complete
> > cleanly.
> 
> Great news. I thought the core of a cherry-pick would be some kind of
> apply-patch.

Well, it could also be done that way.  But then you run into some
issues when it comes to rename detection.

> I was already planning some extra ours in finding out how
> native git does cherry-pick.

It does what I describe above via merge.  I know, because I'm the
one that made native git do that.

> But seems to be that is not needed,
> right? Or are there cases where we don't reuse merge for cherry-pick?

There is no good reason not to use merge.  You want to use the
merge stuff because eventually merge will support rename detection,
and you want to take advantage of that during cherry-pick too.

To be fair you could do a diff with rename detection and then apply
the patch.  But you need to consider renames on both sides, that is
there could be a rename between B and Q that you need to take into
account when you are applying the delta between B and C on top of Q.
Or there could be a rename between B and C that you need to take
into account when applying onto Q.  Merge already has to handle
both cases.  :-)

Also keep in mind revert is just the opposite of cherry-pick.
Given the above diagram, the merge base is C and theirs is B.

-- 
Shawn.