[Python-Dev] gdb support could use some love

[Ned Deily]

On Apr 5, 2018, at 14:48, Terry Reedy <tjreedy at 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
  nad at python.org -- []