If you are a expert and understand how cherry-pick works at a fundamental level, I’d appreciate if you could take a look at this StackOverflow question:

Trying to figure out the best way to merge a specific PR that will make importing datetime significantly faster.

@pganssle not a git expert by any means, but could the c implementation live in something like _cdatatime and have the python one live in datetime instead?

@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 Another option would be to basically put the entire Python implementation in the except block of a try: ... except ImportError construct, but that’s ugly and horrible and also I’m not sure it would play any nicer with git cherry-pick anyway.

@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/ in main, because those files are very close to identical.

@pganssle I wonder if you move the to, and have be a small stub file. git will be smart enough to notice the rename. You'll need to have them in one commit since cherry-pick is explicitly "apply this commit without the history"

also I wonder if the two commit strategy you tried would work if you cherry-pick the two commit in sequence?

@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

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.