Re: Unexpected conflict during cherry-pick after moving submodule

>
> Hi Tamas,
>
> On Mon, Apr 12, 2021 at 9:08 AM Tamas Peregi <tamas.peregi@formlabs.com> wrote:
> >
> > Hi Elijah,
> >
> > thanks for the quick reply and the useful information about the ort strategy!
> >
> > Do I understand correctly that the problem is in the recursive
> > strategy, i.e. inside the cherry-pick step, not the submodule
> > movement? That sounds a bit unfortunate in my case, as I'm the one
> > moving the submodule (then merging it back to master), and others in
> > my company want to cherry-pick over it, so I'm breaking their
> > workflows if I go ahead with moving. (Unless I tell all of them to use
> > the experimental ort strategy instead, which may introduce its own set
> > of problems.) Is there any way of moving the submodule that doesn't
> > break cherry-picking with the default (recursive) strategy? I'm
> > willing to do some extra work to spare confusion by others down the
> > line.
>
> Unfortunately, the recursive merge machinery had a variety of issues
> with submodules (see e.g.
> https://git.kernel.org/pub/scm/git/git.git/commit/?id=aa2faac03ad646873ebac2b230581d1d26dd1b99)
> and yes, the merge machinery is intrinsic to cherry-pick's
> functionality.  I don't have a good workaround for you, short of "wait
> until git-2.32 is released".
>
> > Also: up until now, I thought cherry-pick simply exports the source
> > commit as a patch, then applies it to the target commit, but
> > "recursive" is a merge strategy, correct? So is cherry-pick doing
> > something vastly more complex than I thought, involving merging in the
> > background?
>
> Right, cherry-pick makes use of the merge machinery using a particular
> specially crafted merge while recording it as a regular commit.
> Interestingly, the rebase command has multiple backends, one of which
> used the merge machinery and another that behaved as you thought by
> creating and applying patches.  While the use of an appropriate
> special merge (as done by cherry-pick and rebase) is roughly
> semantically equivalent to what creating and applying patches
> provides, the create-and-apply-patches procedure actually discards
> relevant information and results in some shortcomings that simply
> cannot be fixed.  As such, we switched the default rebase backend from
> "apply" to "merge" as of git-2.26.  If you're curious, read up on the
> "BEHAVIORAL DIFFERENCES" section of the git-rebase(1) manual,
> especially the "Context" section.
>
> Hope that helps,
> Elijah