Re: How to turn off rename detection for cherry-pick?
- From
- Pavel Rappo <pavel.rappo@gmail.com>
- Date
- Aug 29, 2024, 23:12 UTC
- Message-ID
- <CAChcVukzk=-1JNAoffWQEEv4Ne1FozGEwzGuaUWuiwhoHkcUng@mail.gmail.com>
- In-Reply-To
- <20240829214336.GA440013@coredump.intra.peff.net>
You seem to have confirmed my understanding that I described in my initial email (you replied to my second email in this thread).
On Thu, Aug 29, 2024 at 10:43 PM Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> > On Thu, Aug 29, 2024 at 09:47:52AM +0100, Pavel Rappo wrote: > > > The reason I ask this is that we've run into a (probably practically > > rare) case where cherry-pick changes a wrong file. We want to be able > > to detect such cases. > > You can pass merge strategy options on the command line. The old > "recursive" strategy has a "no-renames" option, so: > > git cherry-pick --strategy=recursive -Xno-renames feature > > generates a modify/delete conflict for your example. Curiously, the > modern default, "ort", does not seem to respect that option. You can > bump up the limit to require exact renames, though, which does prevent > the mismerge in your case. Like: > > git cherry-pick -Xfind-renames=100% feature > > There are also other strategies that do not do rename detection, but I > think you are better off using one of the more commonly-used strategies > and just disabling renames. IMHO it's a bug that ort doesn't respect > -Xno-renames. > > -Peff