This intended '\' literally, but it was actually '' because the \'
became just ' (backslash-apostrophe becomes just aspostrophe).

This improves consistency, because most were already. For a few it
allows backslashes to removed, improving readability. Even for the
others, some editors will highlight them as regular expressions now
that they are raw string literals.

These are a couple strings that, in addition to not having any
escape sequences, don't represent regular expressions, Windows
paths, or anything else that would be clarified by raw literals.

In the git.diff.Diff class, the _index_from_patch_format and
_index_from_raw_format methods' docstrings had still described them
as reading from streams, even though they have instead read from
processes (and taken "proc", not "stream", arguments) since gitpython-developers#519
when the change was made in a5db3d3 to fix a freezing bug.

This updates the docstrings to reflect that they read from
processes.

The message refers to the (public) working_tree_dir attribute by
name, so that should be uncapitalized to reflect the case by which
it must be accessed, even when it appears at the beginning of a
sentence.

The git.objects.commit.Commit._deserialize method stopped accepting
a param_from_rev_list argument in ae5a69f, but the documentation
for that parameter was never removed.

Because that was the only part of the method's docstring, and it is
a nonpublic method, and the associated _serialize method does not
have a docstring, this change simply removes the _deserialize
method's docstring without adding anything.

The local (i.e. late) import was removed in 7b3ef45, but the
comment about it on (what was) the preceding line has persisted
until now.

This changes

    master repository

to
    superproject (master repository)

in the RootModule class docstring and in the tutorial, to make even
clearer what this is referring to. This way, users who are less
familiar with submodules will be less likely to confuse this with
a "master" branch (since "master" is one of the popular default
branch names), while users who are more familiar with submodules
and may search for the official term "superproject" will find the
docs when doing so.

This retains "master repository" parenthesized rather than
completely replacing it because although "superproject" is the
official term for this, it is a bit obscure and unintuitive.

Since the hyphen spelling is what the official Git docs use.

This change affects only docstrings.

Reference.set_object explains its handling of oldbinsha by quoting
a comment from refs.c in the Git source code. However, that comment
now appears in refs/files-backend.c in that codebase. This updates
the reference so readers can look it up and find the comment in its
surrounding context.

The commit to the git project's source code that moved the code
that includes that comment is:

git/git@7bd9bcf

This rarely-seen ValueError message had said SymbolicRef, and is
now changed to SymbolicReference.

Since the value of __class__ is a type, comparing it to another
type object should use "is" rather than "==".

Some of these, involving type(), were fixed in bf7af69, but flake8
did not catch the .__class__ variation addressed here.

In the git module (including the modules it contains).

This also makes one small change in doc/ to synchronize with a
change made in a docstring.

The is_cygwin_git function returns False when we have is_win,
because is_win is not True on Cygwin systems. The existing comment
explained why, but was tentative. The claims are accurate, so this
rewrites the comment to state it more definitively.

Within the git module.

In Python 2, it was necessary to inherit from object to have a
new-style class. In Python 3, all classes are new-style classes,
and inheritance from object is implied.

Usually, removing explicit inheritance from object is only a small
clarity benefit while modernizing Python codebases. However, in
GitPython, the benefit is greater, because it is possible to
confuse object (the root of the Python class hierarchy) with
Object (the root of the GitPython subhierarchy of classes
representing things in the git object model).

Most already were, but a few were strings.

Intentionally untouched test modules in this commit:

- Modules where there are no such changes to be made.

- Modules in test/performance/ -- will be done separately.

- test/lib/ modules (these are test *helpers* and will be done
  separately).

- test/test_util.py, because although it has a few comments that
  might be improved, it may make more sense to do that together
  with some further refactoring changes.

It benefits from a docstring because it is not referenced in code
or documentation, and its purpose is/was otherwise unclear.

The docstring includes a reference to gitpython-developers#1188 for more information.

This modifies content of the strings themselves, but only slightly.

- Make an exception message more readable.

- Improve spacing of the "python -c" script string in the sys.path
  test.

This futher improves some wording in docstrings and comments in a
handful of places within the git module.

:return: was used extensively, while :returns: only appeared in two
docstrings.

Changes that fix the message itself:

- Add a missing space between words (two parts were concatenated,
  with no space at the edge of either).

- Capitalize "GitPython" since that is the repo and project name.

Changes that improve how the message is produced:

- Make the entire literal part of the string the format string,
  instead of formatting the first part and concatenating the second
  part.

- Pass the format string and k_env_git_repo variable as separate
  arguments to logging.info, so the logging machinery takes care of
  substituting it for %s, rather than doing the substitution.

This removes the Windows-specific information in the warning
message in git_daemon_launched.

After the associated functionality was updated in gitpython-developers#1684 and the
warning message was abridged accordingly, the functionality was
updated again in gitpython-developers#1697, causing the message to be outdated and no
longer helpeful (since having git-daemon.exe in a PATH directory is
no longer necessary or useful), without any corresponding change to
the message.

In the git module (including modules it contains).

This does not add any new "# end" or "# END" comments. Instead, it
improves the consistency and clarity of existing ones by converting
each "# end" comment to "# END" (since capitalization was not used
systematically to indicate nesting level or other semantic
information, and capitalizing "END" makes clear the nature of the
comment), and by adding some information to a few of the comments.

This also removes end comments that did not provide information or
significant visual indication that a "section" was ending, or where
the visual indication they provided was at least as well provided
by replacing them with a blank line. However, it does *not* attempt
to apply this change everywhere it might be applicable.

As in the recent roughly corresponding change inside git/, this
does not add new END comments (and actually removes some), but
instead focuses on making the existing ones more consistent in
style, mainly adjusting capitalization (turning "end" to "END").

This changes the style "END" comments appearing after local
function definitions from "END def X" to "END X".

Note that this still does not add such comments where they were not
present, it only adjusts their style where they already existed.

This uses the Sphinx ~ notation to express references like:

    :class:`Z <a.b.c.Z>`

In the abbreviated form, which Sphinx renders the same way:

    :class:`~a.b.c.Z`

(This commit also makes some other polishing changes to affected
and nearby text.)

A number of them were incorrect, due to how files were renamed, and
code moved between them, over time. Some were corrected earlier,
and most of the rest are corrected here.

Not all modules have these at all. This does not add any to modules
that don't have them. It only fixes them where present but wrong.

In Python 3, UTF-8 is the default encoding when no encoding
declaration is present, and omitting the encoding declaration when
UTF-8 is intended is officially suggested.

- https://docs.python.org/3/reference/lexical_analysis.html
- https://pep8.org/#source-file-encoding

Furthermore, not all files in this project had them (and their
presence or absence seems to have been mainly for historical
reasons rather than file contents).