It came up in https://bugs.python.org/issue32690 that it's not at all clear how to revert commits to a maintenance branch if we decide that a change shouldn't have been backported after all.
Transferring over my notes from that issue to be cleaned up and added to the dev guide:
check out the branch of interest and ensure it's up to date
For the record, I initialized tried using Github's revert button on the original PR, python/cpython#5390 . However, it unhelpfully said this cannot be reverted automatically.
Next, I went back to my Github account to create the PR but the preview was showing it as many thousands of lines. This indicated that it was being applied against 3.7 instead of 3.6. There was no obvious way to change the target back to 3.6.
From what @rhettinger described, it seems that when reverting using GitHub web UI, GitHub by default selected the master branch, even though it was reverting from the 3.6 branch. I think GitHub should have known better to select the 3.6 branch in this case. 🤔
@ncoghlan, would you like to prepare the PR explaining how to revert? 😄
I'm now thinking that we might need a revert-bot one of these days 😁
All of @rhettinger's steps were right, it's just that in the final PR creation step in the web UI it's necessary to know that there are some dropdowns in the top-left which allow you to choose which branch is the intended destination.
Once you adjust that from master to 3.6, GitHub correctly recalculates the diff and gives you a sensible PR. But if you don't already know the dropdowns are there, then there isn't anything to really draw your attention to them.
Deciding how to add this is actually a bit tricky, since we don't currently discuss git revert at all, not even in the simpler case of reverting a commit to master.
Activity
rhettinger commented on Jan 30, 2018
For the record, I initialized tried using Github's revert button on the original PR, python/cpython#5390 . However, it unhelpfully said this cannot be reverted automatically.
Next I tried command-line git:
Next, I went back to my Github account to create the PR but the preview was showing it as many thousands of lines. This indicated that it was being applied against 3.7 instead of 3.6. There was no obvious way to change the target back to 3.6.
Mariatta commented on Jan 30, 2018
From what @rhettinger described, it seems that when reverting using GitHub web UI, GitHub by default selected the master branch, even though it was reverting from the 3.6 branch. I think GitHub should have known better to select the 3.6 branch in this case. 🤔
@ncoghlan, would you like to prepare the PR explaining how to revert? 😄
I'm now thinking that we might need a revert-bot one of these days 😁
ncoghlan commented on Jan 30, 2018
All of @rhettinger's steps were right, it's just that in the final PR creation step in the web UI it's necessary to know that there are some dropdowns in the top-left which allow you to choose which branch is the intended destination.
Once you adjust that from master to 3.6, GitHub correctly recalculates the diff and gives you a sensible PR. But if you don't already know the dropdowns are there, then there isn't anything to really draw your attention to them.
ncoghlan commented on Jan 30, 2018
Deciding how to add this is actually a bit tricky, since we don't currently discuss git revert at all, not even in the simpler case of reverting a commit to master.
Given that it was the PR interface that caused problems, perhaps it would be more useful to add a section on "Submitting a PR to a maintenance branch"? In https://github.com/python/devguide/blob/master/gitbootcamp.rst#backporting-merged-changes we currently gloss over that bit, since it relies on having cherry_picker.py generate a suitable PR URL.