If you are a #git expert and understand how cherry-pick
works at a fundamental level, I’d appreciate if you could take a look at this StackOverflow question: https://stackoverflow.com/q/75825183/467366
Trying to figure out the best way to merge a specific PR that will make importing datetime
significantly faster.
@shironeko That’s how it already works. Right now import datetime
defines the whole Python implementation, then tries to import the C implementation to overwrite it.
After this change, import datetime
will work more like import zoneinfo
, where it tries to import the C implementation, then on failure it imports the Python implementation.
@shironeko The problem is that I think when you try to git cherry-pick
A onto B, I don’t think git
will go, “Oh let me find the common parent of A and B, following the history of each file to find the target files in B in case they’ve been renamed in either A or B”, I think it looks for a file with the same name in the same location or maybe it does that, then if it doesn’t find one, it looks for a file in B that is sufficiently similar to A that you could call it the same file.
@shironeko If it does the thing where it looks for a similar file, I don’t know why it’s not finding Lib/_datetime.py
in main
, because those files are very close to identical.
@pganssle @shironeko I’m pretty sure it looks for a file with the same name. If you do `mv file1.txt file2.txt` git will think you deleted one and added the other - even if the contents are identical. You have to use `git mv` to track the rename properly. I haven’t tried deleting a file and adding a completely different one with the same name (and am on my phone now) but I’m almost certain it would track that as modifications to the same file
@shironeko Another option would be to basically put the entire Python implementation in the
except
block of atry: ... except ImportError
construct, but that’s ugly and horrible and also I’m not sure it would play any nicer withgit cherry-pick
anyway.