On Apr 5, 2018, at 14:48, Terry Reedy <tjre...@udel.edu> wrote:
> On 4/5/2018 5:47 AM, Skip Montanaro wrote:
>>> There are a bunch of open issues regarding gdb support including one with a 
>>> PR in need of review for 3.6+.
>> I rejected one (which assumed everyone now uses a python-aware gdb),
>> commented on another (ceval.c-related name changes in several
>> commands), and created a PR for third (documentation for the
>> user-defined commands). Unfortunately, it's been so long since I
>> contributed, I don't quite understand the ins and outs of the workflow
>> anymore. In particular, I could find no way to add the "skip news"
>> label. I'm afraid someone might have to intervene here:
>> https://github.com/python/cpython/pull/6384
> 
> You created the PR from your local python repository master branch.  I have 
> done this, with negative consequences.  I believe you will find life with git 
> easier if you never edit your master branch, or at least, never make local 
> commits to it, and only commit to and create PRs from special-purpose patch 
> branches, as described in the devguide.

That's a good observation, Terry.  The main problem is that, when a core 
developer merges the PR from your local repo to the main python/cpython repo, 
we do a squash merge which means that the change or changes committed in the 
python/cpython and included in the PR will end up with a single new hash id 
that differs from what you originally committed in your cpython fork.  So the 
next time you pull to your cpython fork (conventionally "origin") from the main 
cpython repo ("upstream"), there will be a conflict on the "normal" branch, 
i.e. master, 3.7, etc, requiring a merge or rebase, but you don't want to do 
that since the change is already upstream.

Once the PR is merged into the main cpython repo, you can fix the problem by 
force removing the original commit(s) from the "normal" branch in your forked 
repo.  See for example:

https://stackoverflow.com/questions/9646167/clean-up-a-fork-and-restart-it-from-the-upstream

--
  Ned Deily
  n...@python.org -- []

_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to