Hi Elijah, thanks for the expanded reply, I think it cleared everything up. Regards, Tamás On Mon, Apr 12, 2021 at 6:53 PM Elijah Newren <newren@xxxxxxxxx> wrote: > > Hi Tamas, > > On Mon, Apr 12, 2021 at 9:08 AM Tamas Peregi <tamas.peregi@xxxxxxxxxxxx> 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
