Help to Resolve issues with Pull request 25220
All, Can someone better than me (i.e anyone) help me resolve the issues with Pull Request 25220. I followed the dev guide, but I assume that between me taking my fork of the cpython repository, and building my pull request, another pull request was merged into master. It also appears that the Documentation build is failing with an rst reference tag error on part of the document I never changed. I am finding it difficult to drive github to understand how to resolve the conflict (i.e how to retain both sets of changes) - so any help would be appreciated. Regards, -- Anthony Flury *Moble*: +44 07743 282707 *Home*: +44 (0)1206 391294 *email*: anthony.flury@btinternet.com mailto:anthony.flury@btinternet.com
Hi Anthony, It looks like you’ve incorporated several other changes into your commit by mistake. The simplest thing to do might be to re-create your git branch and PR from scratch. If conflicting changes land while your PR is still open, you’ll need to do something called a “rebase”. The git book https://git-scm.com/book/en/v2/Git-Branching-Rebasing explains this well. Barney On Wed, 7 Apr 2021 at 11:22, anthony.flury via Python-Dev < python-dev@python.org> wrote:
All,
Can someone better than me (i.e anyone) help me resolve the issues with Pull Request 25220.
I followed the dev guide, but I assume that between me taking my fork of the cpython repository, and building my pull request, another pull request was merged into master.
It also appears that the Documentation build is failing with an rst reference tag error on part of the document I never changed.
I am finding it difficult to drive github to understand how to resolve the conflict (i.e how to retain both sets of changes) - so any help would be appreciated.
Regards, -- Anthony Flury *Moble*: +44 07743 282707 *Home*: +44 (0)1206 391294 *email*: anthony.flury@btinternet.com _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/EPLT4DTJ... Code of Conduct: http://python.org/psf/codeofconduct/
On 4/7/2021 12:32 PM, Barney Gale wrote:
It looks like you’ve incorporated several other changes into your commit by mistake. The PR definitely has too many changes unrelated to the issue. I recognize a few of the changes as related to recent merges.
My guess that the the issue-43737 branch was branched off of something other than master, which is usually a fatal mistake. The parent branch may also have been branched off of something other than master. Tony, with rare exception, each branch should be branched directly off master, which means checking out master first each time. There is probably some other bad sequence of events that could cause the issue. The simplest thing to do might be to re-create your git
branch and PR from scratch.
I agree with this. That means updating the master branch, creating a new 43737 branch, make the 43737 changes, commit, and push. Or, in case problem is elsewise, fix the merge conflict (below), merge, and push to your fork. Update your master from upstream, change to branch, git merge upstream/master, commit to branch, push branch to fork, and see how things work.
If conflicting changes land while your PR is still open, you’ll need to do something called a “rebase”.
Rebasing (perhaps done incorrectly) often makes things worse. One fixes a merge conflix by editing the PR branch file(s) with the conflict and committing a change. However, the merge conflict in expression.rst is this: <<<<<<< issue-43737 .. productionlist:: lambda_expr: "lambda" [`parameter_list`]: `expression` lambda_expr_nocond: "lambda" [`parameter_list`]: `expression_nocond` ======= .. productionlist:: python-grammar lambda_expr: "lambda" [`parameter_list`] ":" `expression`
> master
Adding a grammar production has nothing to do with the issue. This could be easily fixed by removing the lambda_expr_nocond line (and other junk if not editing in the local branch) but would not solve the more extensive issues. -- Terry Jan Reedy
Terry, Barney, I think I have done it right now - I have no idea what went wrong last time. I fixed it by recreating the changes from scratch, and scrupulously checking for the differences. Thanks for your help - although ultimately I didn't try to rebase. -- On 08/04/2021 01:32, Terry Reedy wrote:
On 4/7/2021 12:32 PM, Barney Gale wrote:
It looks like you’ve incorporated several other changes into your commit by mistake. The PR definitely has too many changes unrelated to the issue. I recognize a few of the changes as related to recent merges.
My guess that the the issue-43737 branch was branched off of something other than master, which is usually a fatal mistake. The parent branch may also have been branched off of something other than master.
Tony, with rare exception, each branch should be branched directly off master, which means checking out master first each time.
There is probably some other bad sequence of events that could cause the issue.
The simplest thing to do might be to re-create your git
branch and PR from scratch.
I agree with this. That means updating the master branch, creating a new 43737 branch, make the 43737 changes, commit, and push.
Or, in case problem is elsewise, fix the merge conflict (below), merge, and push to your fork. Update your master from upstream, change to branch, git merge upstream/master, commit to branch, push branch to fork, and see how things work.
If conflicting changes land while your PR is still open, you’ll need to do something called a “rebase”.
Rebasing (perhaps done incorrectly) often makes things worse. One fixes a merge conflix by editing the PR branch file(s) with the conflict and committing a change.
However, the merge conflict in expression.rst is this:
<<<<<<< issue-43737 .. productionlist:: lambda_expr: "lambda" [`parameter_list`]: `expression` lambda_expr_nocond: "lambda" [`parameter_list`]: `expression_nocond` ======= .. productionlist:: python-grammar lambda_expr: "lambda" [`parameter_list`] ":" `expression`
>> master
Adding a grammar production has nothing to do with the issue. This could be easily fixed by removing the lambda_expr_nocond line (and other junk if not editing in the local branch) but would not solve the more extensive issues.
participants (4)
-
anthony.flury -
Barney Gale -
Terry Reedy -
Tony Flury