[Python-Dev] Committing a bug fix

[Terry Reedy]

On 9/28/2015 1:12 PM, Alexander Belopolsky wrote:
>
> On Mon, Sep 28, 2015 at 4:13 AM, Terry Reedy <tjreedy at udel.edu
> <mailto:tjreedy at udel.edu>> wrote:
>
>     Normal one specified in devguide: commit 3.4, merge 3.5, merge 3.6,
>
>
> That's exactly what I did at fist, but apparently while I was doing
> this, another commit was pushed to all three branches.

You lost a push race.  To minimize to possibility of that, I get 
everything ready so that I can commit and merge with under 15 (or 20) 
mouse clicks, without editing anything, after a final pull that does not 
pull anything.  (Sunday, I left out the 'clean repository' check and the 
the final 'nothing found' pull.  I have a .bat file to pull into default 
and update all 4 working directory branches.)  With everything set up, I 
can commit to 2.7 and 3.4 and merge into 3.5 and 3.6 in under a minute. 
  This means having no merge conflicts or having them 'pre-resolved' -- 
see below.

> To recover, I did a series of hg update 3.x; hg merge dances
 > fighting with Misc/NEWS on every turn.

Hg almost never merges Idle news items correctly, even when there is no 
real conflict, and even when it says there was no conflict.  In the 
latter case, it may have merged in the wrong place, such as putting a 
things into the 3.5.1 section of 3.6 NEWS, which should not be there. 
So I assume that NEWS merges will always be wrong.  After what I hope 
will be the next to last pull, when everything else is done, I open 2.7, 
3.4, 3.5, and 3.6 NEWS on separate tabs (of Notepad++), edit 2.7 and 
save, copy-paste to 3.4 news and save, then copy-paste into 3.5 and 3.6 
WITHOUT saving.  After merging into 3.5, before commiting, I revert NEWS 
to local, switch to Notepad++, being sure to click [No] File changed, 
reload?, save the correct 3.5 NEWS, mark resolved, and commit.  Ditto 
for 3.6.  (I do this in batches, when no one else seems active.)

-- 
Terry Jan Reedy