In CPython, the current implementation of the datetime module defines all the classes and methods of datetime in Python, then imports all that same stuff from a faster C implementation (the _datetime module), overriding or deleting all the Python implementations if the C implementation is available. This happens every time you import datetime, but that's pretty wasteful. We're hoping to re-organize the code so that import datetime first checks for the C implementation and, if it fails to import that, instead import from a _pydatetime module.
This is a simple enough change, but it comes at a maintenance cost — because we support older versions for several years, we generally work on the main branch and backport appropriate changes to older branches. We have a bot that uses git to automatically cherry-pick new PRs onto old branches.
The problem we're having is that when we re-organize the code in this way, git no longer seems to know that when I make changes to Lib/_pydatetime.py, I want the changes backported on to Lib/datetime.py in older branches. In this branch, I have tried using two commits, one that moves Lib/datetime.py to Lib/_pydatetime.py and a second that re-introduces Lib/datetime.py, then introduced a change in Lib/pydatetime.py. When I try git cherry-pick <commit-id> (where commit-id is the head of the move_pydatetime branch), I get a merge conflict because main doesnt have a Lib/pydatetime branch.
My question for y'all git experts out there is: is there a strategy that will make it possible to cleanly cherry-pick changes in Lib/_pydatetime.py directly into the backport branches, or is there some reason that this cannot work in principle?
Ezio Melotti did some investigations on strategies here, and could not find one that works.
Note: I am really only looking for answers that involve how I structure the commits when making this change, since I'm looking to avoid special-casing Lib/_pydatetime.py / Lib/datetime.py in the bot (if I can even do this). If there's no way to get git to understand natively that Lib/_pydatetime.py in the post-change world should map to Lib/datetime.py` in the pre-change world, I just want to know that that's true, and I will figure out workarounds (or manually backport all changes until the pre-change branches are all out of support — there are only a few of these each year).
Edit: The answers to Is it possible to move/rename files in Git and maintain their history? hint that this may not be possible, but some say "yes" and other say "no", some involve rewriting history (which we cannot do here) and others focus on how to follow the history using git log --folow. They certainly suggest that this may not be possible, but do not specifically address how git cherry-pick works in such a way that I am confident saying, "Ah yes, there is no way to structure these changes to the repository in such a way that git cherry-pick cannot follow them."
I think the biggest additional wrinkle that this particular question adds is the fact that Lib/datetime.py will exist both before and after the change, but it will represent two fundamentally different files. I'm OK with changes to Lib/datetime.py not being backportable to before the change, but changes to Lib/pydatetime.py need to map to pre-change Lib/datetime.py.
