如何调整提交结构，使Git可将_pydatetime.py变更干净cherry-pick至旧分支？

在CPython中，当前datetime模块的实现是先在Python中定义所有类和方法，再从更快的C实现（_datetime模块）导入相同内容，若C实现可用则覆盖或删除Python实现。每次import datetime都会执行此操作，存在性能浪费。我们计划重构代码，让import datetime先检查C实现，若导入失败则从_pydatetime模块导入。

这一改动本身简单，但带来维护成本：我们需长期支持旧版本，通常在main分支开发后将合适变更回退至旧分支，并有机器人用Git自动cherry-pick新PR到旧分支。

问题在于，重构代码后，Git无法识别对Lib/_pydatetime.py的变更需回退到旧分支的Lib/datetime.py。我尝试分两次提交：先将Lib/datetime.py移至Lib/_pydatetime.py，再重新创建Lib/datetime.py，之后修改Lib/_pydatetime.py。执行git cherry-pick <commit-id>（commit-id为该分支的HEAD）时出现合并冲突，因为旧分支没有Lib/_pydatetime.py。

向Git专家请教：是否有策略可让Lib/_pydatetime.py的变更能直接干净cherry-pick到回退分支？还是原则上不可行？

Ezio Melotti曾研究过相关策略，但未找到可行方案。

注：我仅寻求通过调整提交结构解决的方案，希望避免在机器人中对Lib/_pydatetime.py/Lib/datetime.py做特殊处理。若Git无法原生识别变更后Lib/_pydatetime.py对应变更前的Lib/datetime.py，也请告知，我会另行寻找变通方案。

补充：有关于“移动/重命名Git文件是否能保留历史”的讨论暗示这可能不可行，但观点不一，部分涉及重写历史（我们无法这么做），部分聚焦git log --follow追踪历史。这些讨论未明确说明Git cherry-pick的工作机制，无法让我确定是否存在可行的提交结构。

本问题的特殊之处在于：变更前后Lib/datetime.py都存在，但已是完全不同的文件。我不要求变更后Lib/datetime.py的变更能回退到旧版本，但Lib/_pydatetime.py的变更需对应到变更前的Lib/datetime.py。

内容的提问来源于stack exchange，提问作者Paul