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

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

Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> > 
> > It does what I describe above via merge.  I know, because I'm the
> > one that made native git do that.
> 
> Oh...!
> 
> I am not sure I agree with Shawn on that one. Attribution is something I 
> take very seriously.
> 
> 48313592 9509af68

Doh.  Those are Junio implementing it in scripts, but without
rename detection.  Thanks for the correction.  :-)

I was actually thinking of:

  commit a970e84e8ad23a740e456fb4191ed61becef8989
  Author: Shawn O. Pearce <spearce@xxxxxxxxxxx>
  Date:   Thu Dec 28 02:35:24 2006 -0500

    Allow merging bare trees in merge-recursive.
    
    To support wider use cases, such as from within `git am -3`, the
    merge-recursive utility needs to accept not just commit-ish but
    also tree-ish as arguments on its command line.
    
    If given a tree-ish then merge-recursive will create a virtual commit
    wrapping it, with the subject of the commit set to the best name we
    can derive for that tree, which is either the command line string
    (probably the SHA1), or whatever string appears in GITHEAD_*.
    
    Signed-off-by: Shawn O. Pearce <spearce@xxxxxxxxxxx>
    Signed-off-by: Junio C Hamano <junkio@xxxxxxx>

But maybe that still came after the first use of merge-recursive
for cherry-pick or revert.
 
> > > 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.
> 
> There is. It is slow. The intelligent thing would be to try something 
> simple first, and that failing, try something more complicated, and only 
> then resort to the ultimate solution.
> 
> It is not done that way in C Git (which Shawn calls "native"). That is why 
> git-rebase is still _way_ faster than git-rebase -m.

I'm not sold on that.  I think the reason we see a performance
difference in C Git is implementation details and not general
algorithm issues.
 
> > 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.
> 
> True, rename detection is something you want to do. But you can still do 
> that with format-patch -M | apply, which should be faster than a 
> full-blown cherry-pick in almost all cases. By an order of magnitude.

But that doesn't handle case of Q renaming one of the files that
C modified.  Yet you want to handle that during a cherry-pick
or a revert, because you still want the delta attached to the
new location.
 
-- 
Shawn.