Sure, I sort of asked this in the past: what are the generated files, how
to identify them, is there a pattern?

I need to dig up that thread and find out if anyone answered. It's been a
while :)

Usually there would be conflict in backport though. It was suggested that
cherry-picker can regenerate the files and resolve the conflict.
Your suggestion of having miss Islington comment on the PR sounds good too.

On Feb 2, 2018 8:17 PM, "Barry Warsaw" <> wrote:

I’m in the process of back porting a change which touches importlib and
requires regeneration of Python/importlib.h and Python/importlib_external.h.

The original fix on master:

Miss Islington’s back port to 3.7:

Miss Islington was not able to auto-pick this into 3.6, which makes sense.

I got a little concerned though that the back port touches those two
generated files, and didn’t feel comfortable just pushing the Big Green
Button.  I chatted with Brett and he also agreed that the merge should
probably be done manually.  So for the 3.7 merge, I actually followed the
GitHub CLI merge instructions, regenerated the .h files, pushed the branch,
and opened a new PR:

Once CI passed, I hit the BGB and the merge occurred as normal.

For the 3.6 fix, I used cherry_pick, resolved the conflicts manually,
regen’d the header files, pushed the branch, and submitted a new PR:

This one’s still running CI, but if it passes, I’ll merge it.

I wanted to mention this because maybe Miss Islington should flag, warn, or
otherwise indicate when autogenerated files are being merged?  Are there
any other files other than the importlib .h files that we should take extra
care with?


python-committers mailing list
Code of Conduct:
python-committers mailing list
Code of Conduct:

Reply via email to