| Message ID | 20220116160550.514637-1-jholdsworth@nvidia.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | git-p4: Various code tidy-ups | expand |
Joel Holdsworth <jholdsworth@nvidia.com> writes: > This third version of the patch-set is rebased on top of the next > branch. After other p4 topics in 'next' graduate to 'master', you'd need to rebase the series again to the updated 'master', but in the meantime, people can comment on the current patches. I'll take the series as "for discussion only" for now. Thanks. cf. Documantation/SubmittingPatches::[[base-branch]] * In the exceptional case that a new feature depends on several topics not in `master`, start working on `next` or `seen` privately and send out patches for discussion. Before the final merge, you may have to wait until some of the dependent topics graduate to `master`, and rebase your work.
Between CI runs https://github.com/git/git/actions/runs/1705530485 and https://github.com/git/git/actions/runs/1705883104 the only difference is that the former has this topic merged while the latter does not. > Patches to correct these items may be provided later. cf. https://github.com/git/git/runs/4834693492?check_suite_focus=true#step:5:1586 cf. https://github.com/git/git/runs/4834693517?check_suite_focus=true#step:5:1643 That is another thing to correct. > This third version of the patch-set is rebased on top of the next > branch. By the way, to try it out, I pretended that you followed the advice in the SubmittingPatches document, namely: cf. Documentation/SubmittingPatches::[[base-branch]] * A new feature should be based on `master` in general. If the new feature depends on other topics that are in `next`, but not in `master`, fork a branch from the tip of `master`, merge these topics to the branch, and work on that branch. You can remind yourself of how you prepared the base with `git log --first-parent master..`. So, the patches are queued like so: $ git log --oneline --first-parent master..jh/p4-various-fixups 818dd3982a git-p4: seperate multiple statements onto seperate lines 0742a3fb0f git-p4: move inline comments to line above e34dcdaa6d git-p4: only seperate code blocks by a single empty line 5d2c48612b git-p4: compare to singletons with "is" and "is not" cc2572b455 git-p4: normalize indentation of lines in conditionals 3ae33c2d87 git-p4: ensure there is a single space around all operators 6f4806cc58 git-p4: ensure every comment has a single # 34f7c77da5 git-p4: remove spaces between dictionary keys and colons 8c59479063 git-p4: remove redundant backslash-continuations inside brackets 26c76f8db0 git-p4: remove extraneous spaces before function arguments eb7c7a9975 git-p4: place a single space after every comma d33eccbd7b git-p4: removed brackets when assigning multiple return values 3465b01a94 git-p4: remove spaces around default arguments f806563768 git-p4: remove padding from lists, tuples and function arguments 555e0c358a git-p4: sort and de-duplcate pylint disable list 882a0dfd22 git-p4: remove commented code 6483f061f7 git-p4: convert descriptive class and function comments into docstrings 85c22c0c22 git-p4: improve consistency of docstring formatting bab9c087e7 git-p4: indent with 4-spaces fb8c71c28b git-p4: remove unneeded semicolons from statements b66e36e374 git-p4: add blank lines between functions and class definitions d8d4f440a5 Merge branch 'jh/p4-spawning-external-commands-cleanup' into jh/p4-... f3e99f0e9c Merge branch 'jh/p4-fix-use-of-process-error-exception' into jh/p4-... which was created by $ git checkout -B jh/p4-various-fixups v2.35.0-rc1 $ git merge --no-edit jh/p4-fix-use-of-process-error-exception $ git merge --no-edit jh/p4-spawning-external-commands-cleanup $ git am -s ./+jh21-v3-p4-various-fixups where ./+jh21-v3-p4-various-fixups is the mbox file with these 21 patches, and jh/p4-* are the two topic branches form you that are still in 'next'. This way, you still have to wait for these two topics to graduage before this new series can go in, but you won't be taken hostage by other unrelated topics in 'next'. It probably is a good idea to do the same when you prepare the next round of this series. I've ejected this topic from 'seen', but the topic itself should still be there in https://github.com/gitster/git/ repository. Thanks.
> After other p4 topics in 'next' graduate to 'master', you'd need to rebase the > series again to the updated 'master', but in the meantime, people can > comment on the current patches. Hi Junio, Thanks for reviewing my patch-set. I'm trying to figure out how to proceed. At what point will the next branch be merged into master? At the point of the next release, or before? I couldn't find any information about it. The SubmittingPatches guide talks about branching off master, and merging the prerequisite topic branches. For this patch-set I will need: * jh/p4-spawning-external-commands-cleanup * jh/p4-fix-use-of-process-error-exception * ab/config-based-hooks-2 If I then do "git send-email [...] origin/master" you will get all these patches included in my emails. Is this expected? It seems undesirable. For reference, I have made a branch with these merges and rebased the tidy-ups patch-set here: https://github.com/jhol/git/commits/tidy-ups-submit-4 It's no problem to structure the patch-set in any way that is most desirable, so if you could let me know what is expected I am happy to make it happen. Best Regards Joel Holdsworth
Joel Holdsworth <jholdsworth@nvidia.com> writes: > At what point will the next branch be merged into master? At the > point of the next release, or before? I couldn't find any > information about it. Each topic that is in 'next' is merged to 'master' individually when it is ready, so topics A, B, and C may have got merged to 'next' in this order, but only A and C may be merged while B may stay in 'next' while waiting for necessary follow-on work. The answer is "'next' is never merged as a whole to 'master'". From time to time, the tip of 'next' and 'master' may happen to have the same tree when all topics merged to 'next' have graduated to 'master' while no new topics become ready for 'next', but that is a mere coincidence and not a designed part of the workflow. Perhaps looking for "Note from the maintainer" in the list archive would find more info, hopefully? > The SubmittingPatches guide talks about branching off master, and merging the prerequisite topic branches. For this patch-set I will need: > > * jh/p4-spawning-external-commands-cleanup > * jh/p4-fix-use-of-process-error-exception > * ab/config-based-hooks-2 Correct. FWIW, I was updating the "What's cooking" report and am planning to propose merging the first two to 'master' either today or tomorrow as part of the first batch, and the last one in the next batch after a few days. > If I then do "git send-email [...] origin/master" you will get all > these patches included in my emails. Is this expected? It seems > undesirable. You'd use "git format-patch [...] $BASE" where $BASE is the commit you'll locally create by merging these prerequisite topics to 'master'. Thanks.
Hi Junio, > Perhaps looking for "Note from the maintainer" in the list archive would find > more info, hopefully? Thanks for the info. I'll check it out. > > The SubmittingPatches guide talks about branching off master, and > merging the prerequisite topic branches. For this patch-set I will need: > > > > * jh/p4-spawning-external-commands-cleanup > > * jh/p4-fix-use-of-process-error-exception > > * ab/config-based-hooks-2 > > Correct. FWIW, I was updating the "What's cooking" report and am planning > to propose merging the first two to 'master' either today or tomorrow as part > of the first batch, and the last one in the next batch after a few days. Good stuff. It sounds like the easiest thing is for me to resubmit some time next week as and when the patch-sets hit master. > You'd use "git format-patch [...] $BASE" where $BASE is the commit you'll > locally create by merging these prerequisite topics to 'master'. Makes sense. And I suppose the cover letter would have to list out the dependencies? - because otherwise you won't see any merge commits in the emails. Joel
Joel Holdsworth <jholdsworth@nvidia.com> writes: > Makes sense. And I suppose the cover letter would have to list out > the dependencies? - because otherwise you won't see any merge > commits in the emails. Yes, more importantly, I wouldn't know unless you tell me where to apply your patches (well, I usually can guess correctly, but I do not want to guess and be incorrect, which would waste everybody's time). Thanks.
This patch set contains multiple patches to improve consistency and tidyness of the git-p4 script's code style. Many of these patches have been driven by the guidlines contained in the Python PEP8 "Style Guide for Python Code" and were applied using a mixture of human intervention, and tools including autopep8 and pycodestyle. This patch-set stops short of bringing git-p4 into full PEP8 compliance, most notably in regard to the following items: - There is no patch to apply the recommended column limit of 79-characters, - There is no patch to correct hanging indents of multi-line declarations such as multi-line function delcarations, function invocations, etc. Patches to correct these items may be provided later. This third version of the patch-set is rebased on top of the next branch. Joel Holdsworth (21): git-p4: add blank lines between functions and class definitions git-p4: remove unneeded semicolons from statements git-p4: indent with 4-spaces git-p4: improve consistency of docstring formatting git-p4: convert descriptive class and function comments into docstrings git-p4: remove commented code git-p4: sort and de-duplcate pylint disable list git-p4: remove padding from lists, tuples and function arguments git-p4: remove spaces around default arguments git-p4: removed brackets when assigning multiple return values git-p4: place a single space after every comma git-p4: remove extraneous spaces before function arguments git-p4: remove redundant backslash-continuations inside brackets git-p4: remove spaces between dictionary keys and colons git-p4: ensure every comment has a single # git-p4: ensure there is a single space around all operators git-p4: normalize indentation of lines in conditionals git-p4: compare to singletons with "is" and "is not" git-p4: only seperate code blocks by a single empty line git-p4: move inline comments to line above git-p4: seperate multiple statements onto seperate lines git-p4.py | 890 ++++++++++++++++++++++++++++++++---------------------- 1 file changed, 528 insertions(+), 362 deletions(-)