mbox series

[v2,00/21] git-p4: Various code tidy-ups

Message ID 20220113134728.23192-1-jholdsworth@nvidia.com (mailing list archive)
Headers show
Series git-p4: Various code tidy-ups | expand

Message

Joel Holdsworth Jan. 13, 2022, 1:47 p.m. UTC
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 second version of the patch-set incoorporates comments made by Eric
Sunshine.

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 | 888 ++++++++++++++++++++++++++++++++----------------------
 1 file changed, 527 insertions(+), 361 deletions(-)

Comments

Junio C Hamano Jan. 13, 2022, 11:03 p.m. UTC | #1
Doesn't this conflict with your own topics that are already cooking
in 'next'?  For example, I am seeing many conflicts like this one.

    def rebase(self):
        if os.system("git update-index --refresh") != 0:
<<<<<<< HEAD
            die("Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up to date or stash away all your changes with git stash.");
        if len(read_pipe(["git", "diff-index", "HEAD", "--"])) > 0:
            die("You have uncommitted changes. Please commit them before rebasing or stash them away with git stash.");
||||||| 1ffcbaa1a5
            die("Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up to date or stash away all your changes with git stash.");
        if len(read_pipe("git diff-index HEAD --")) > 0:
            die("You have uncommitted changes. Please commit them before rebasing or stash them away with git stash.");
=======
            die("Some files in your working directory are modified and different than what is in your index. You can use git update-index <filename> to bring the index up to date or stash away all your changes with git stash.")
        if len(read_pipe("git diff-index HEAD --")) > 0:
            die("You have uncommitted changes. Please commit them before rebasing or stash them away with git stash.")
>>>>>>> jh/p4-code-tidy-ups

As new things in 'next' that are not in 'master' are not moving
until the final release of this cycle, perhaps this needs to wait
until much later in the month (see tinyurl.com/gitCal).

Thanks.
Joel Holdsworth Jan. 14, 2022, 6:32 p.m. UTC | #2
> As new things in 'next' that are not in 'master' are not moving until the final
> release of this cycle, perhaps this needs to wait until much later in the month
> (see tinyurl.com/gitCal).

I was not sure where the patches ought to be based. I can rebase them on top of 'next' if that would be helpful and/or if you need me to delay them to the end of the month, that's no problem.

Joel