Re: Unexpected conflict during cherry-pick after moving submodule

From: Elijah Newren <newren@gmail.com>
Date: Apr 12, 2021, 16:53 UTC
Message-ID: <CABPp-BHASo5CFejED8CFbB1zszAaQW1Q8yitUdqW-wi8eFuvWg@mail.gmail.com>
In-Reply-To: <CAKJ37Dc5-rOeN_=vq5P3=z=_1bqGFRuFhuWde6cS0vGg3mkLnQ@mail.gmail.com>

Hi Tamas,

On Mon, Apr 12, 2021 at 9:08 AM Tamas Peregi <tamas.peregi@formlabs.com> wrote:

Show 16 quoted lines

>
> 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".

Show 5 quoted lines

> 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