many: Fix title case of Git references (#1938) (#1941)

patchback[bot] · brlin-tw · web-flow · commit 133abd153c7c · 2024-09-25T08:01:24.000+02:00
* many: Fix title case of Git references Currently many references of the Git software don't use title case, this patch fixes them while leaving those that should remain lowercase intact: * `git` command call in code blocks. * Git references in changelog entries should stay consistent with the revision title. Fixes #1935. Signed-off-by: 林博仁(Buo-ren Lin) <buo.ren.lin@gmail.com> * Update docs/docsite/rst/dev_guide/testing_integration.rst Fix command markup. Co-authored-by: Felix Fontein <felix@fontein.de> * Update hacking/README.md Also fix title case of Python. Co-authored-by: Felix Fontein <felix@fontein.de> --------- Signed-off-by: 林博仁(Buo-ren Lin) <buo.ren.lin@gmail.com> Co-authored-by: Felix Fontein <felix@fontein.de> (cherry picked from commit dce7507) Co-authored-by: 林博仁 Buo-ren Lin <Buo.Ren.Lin@gmail.com>
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
@@ -40,7 +40,7 @@ nondescriptive commit messages.
 For other more complex changes—especially those that involve the docs build
 scripts or other tooling code—it may be desirable to preserve the full commit
 history to keep logical changes separated and avoid clobbering useful metadata
-so the git history remains useful in the future. The maintainer who merges the
+so the Git history remains useful in the future. The maintainer who merges the
 PR can select the merge mode through the dropdown menu next to the green merge
 button.
 Generally, maintainers should apply PRs using `Squash and merge`.
diff --git a/docs/docsite/rst/collections_guide/collections_installing.rst b/docs/docsite/rst/collections_guide/collections_installing.rst
@@ -109,7 +109,7 @@ You can also include signatures in addition to those provided by the distributio
 
    ansible-galaxy collection install my_namespace.my_collection --signature https://examplehost.com/detached_signature.asc --keyring ~/.ansible/pubring.kbx
 
-GnuPG verification only occurs for collections installed from a distribution server. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files.
+GnuPG verification only occurs for collections installed from a distribution server. User-provided signatures are not used to verify collections installed from Git repositories, source directories, or URLs/paths to tar.gz files.
 
 You can also include additional signatures in the collection ``requirements.yml`` file under the ``signatures`` key.
 
@@ -202,7 +202,7 @@ Installing a collection from source files
 
 .. include:: ../shared_snippets/installing_collections_file.rst
 
-Installing a collection from a git repository
+Installing a collection from a Git repository
 ---------------------------------------------
 
 .. include:: ../shared_snippets/installing_collections_git_repo.txt
diff --git a/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst b/docs/docsite/rst/community/collection_contributors/collection_release_with_branches.rst
@@ -255,7 +255,7 @@ Releasing when more minor versions are expected
       The format is reStructuredText but not a list as for regular changelog fragments.
       This text will be inserted into the changelog.
 
-  Add to git and commit.
+  Add to Git and commit.
 
 5. Generate the changelogs.
 
diff --git a/docs/docsite/rst/community/collection_contributors/collection_requirements.rst b/docs/docsite/rst/community/collection_contributors/collection_requirements.rst
@@ -375,15 +375,15 @@ and lower barriers to contribution.
 Repository management
 =====================
 
-* Every collection MUST have a public git repository.
+* Every collection MUST have a public Git repository.
 * Releases of the collection MUST be tagged in its repository.
 
   * The ``git`` utility with the ``tag`` argument MUST be used to tag the releases.
   * The tag name MUST exactly match the Galaxy version number.
   * Tag names MAY have a ``v`` prefix.
   * Tag names MUST have a consistent format from release to release.
 
-* Collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's git repository as that release.
+* Collection artifacts released to Galaxy MUST be built from the sources that are tagged in the collection's Git repository as that release.
 
   * Any changes made during the build process MUST be clearly documented so the collection artifact can be reproduced.
 
diff --git a/docs/docsite/rst/community/documentation_contributions.rst b/docs/docsite/rst/community/documentation_contributions.rst
@@ -6,7 +6,7 @@ Contributing to the Ansible Documentation
 
 Ansible has a lot of documentation and a small team of writers. Community support helps us keep up with new features, fixes, and changes.
 
-Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText <https://docutils.sourceforge.io/rst.html>`_ (rST). Some collection-level documentation is written in a subset of `Markdown <https://github.com/ansible/ansible/issues/68119#issuecomment-596723053>`_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need git experience, if you use the ``Edit on GitHub`` option.
+Improving the documentation is an easy way to make your first contribution to the Ansible project. You do not have to be a programmer, since most of our documentation is written in YAML (module documentation) or `reStructuredText <https://docutils.sourceforge.io/rst.html>`_ (rST). Some collection-level documentation is written in a subset of `Markdown <https://github.com/ansible/ansible/issues/68119#issuecomment-596723053>`_. If you are using Ansible, you already use YAML in your playbooks. rST and Markdown are mostly just text. You do not even need Git experience, if you use the ``Edit on GitHub`` option.
 
 If you find a typo, a broken example, a missing topic, or any other error or omission on this documentation website, let us know. Here are some ways to support Ansible documentation:
 
diff --git a/docs/docsite/rst/community/maintainers_workflow.rst b/docs/docsite/rst/community/maintainers_workflow.rst
@@ -51,7 +51,7 @@ Collection maintainers are responsible for releasing new versions of a collectio
 
 #. Planning and announcement.
 #. Generating a changelog.
-#. Creating a release git tag and pushing it.
+#. Creating a release Git tag and pushing it.
 #. Automatically publishing the release tarball on `Ansible Galaxy <https://galaxy.ansible.com/>`_ through the `Zuul dashboard <https://dashboard.zuul.ansible.com/t/ansible/builds?pipeline=release>`_.
 #. Final announcement.
 #. Optionally, `file a request to include a new collection into the Ansible package <https://github.com/ansible-collections/ansible-inclusion>`_.
diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst
@@ -40,7 +40,7 @@ Sublime
 
 A closed-source, subscription GUI text editor. You can customize the GUI with themes and install packages for language highlighting and other refinements. You can install Sublime on Linux, macOS and Windows. Useful Sublime plugins include:
 
-* `GitGutter <https://packagecontrol.io/packages/GitGutter>`_ - shows information about files in a git repository.
+* `GitGutter <https://packagecontrol.io/packages/GitGutter>`_ - shows information about files in a Git repository.
 * `SideBarEnhancements <https://packagecontrol.io/packages/SideBarEnhancements>`_ - provides enhancements to the operations on Sidebar of Files and Folders.
 * `Sublime Linter <https://packagecontrol.io/packages/SublimeLinter>`_ - a code-linting framework for Sublime Text 3.
 * `Pretty YAML <https://packagecontrol.io/packages/Pretty%20YAML>`_ - prettifies YAML for Sublime Text 2 and 3.
diff --git a/docs/docsite/rst/dev_guide/developing_collections_contributing.rst b/docs/docsite/rst/dev_guide/developing_collections_contributing.rst
@@ -4,7 +4,7 @@
 Contributing to collections
 ***************************
 
-If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``).
+If you want to add functionality to an existing collection, modify a collection you are using to fix a bug, or change the behavior of a module in a collection, clone the Git repository for that collection and make changes on a branch. You can combine changes to a collection with a local checkout of Ansible (``source hacking/env-setup``).
 You should first check the collection repository to see if it has specific contribution guidelines. These are typically listed in the README.md or CONTRIBUTING.md files within the repository.
 See :ref:`collection_quickstart` for more general guidelines and :ref:`testing_running_locally` for testing guidelines.
 
diff --git a/docs/docsite/rst/dev_guide/developing_collections_creating.rst b/docs/docsite/rst/dev_guide/developing_collections_creating.rst
@@ -42,7 +42,7 @@ There are a few special namespaces:
 
 :local:
 
-  The `local namespace <https://galaxy.ansible.com/ui/namespaces/local/>`_ does not contain any collection on Ansible Galaxy, and the intention is that this will never change. You can use the ``local`` namespace for collections that are locally on your machine or locally in your git repositories, without having to fear collisions with actually existing collections on Ansible Galaxy.
+  The `local namespace <https://galaxy.ansible.com/ui/namespaces/local/>`_ does not contain any collection on Ansible Galaxy, and the intention is that this will never change. You can use the ``local`` namespace for collections that are locally on your machine or locally in your Git repositories, without having to fear collisions with actually existing collections on Ansible Galaxy.
 
 .. _creating_new_collections:
 
diff --git a/docs/docsite/rst/dev_guide/developing_collections_distributing.rst b/docs/docsite/rst/dev_guide/developing_collections_distributing.rst
@@ -301,7 +301,7 @@ Installing your collection locally
 You have two options for installing your collection locally:
 
   * Install your collection locally from the tarball.
-  * Install your collection locally from your git repository.
+  * Install your collection locally from your Git repository.
 
 Installing your collection locally from the tarball
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
@@ -316,10 +316,10 @@ Install the tarball into a directory configured in :ref:`COLLECTIONS_PATHS` so A
 
 .. _collections_scm_install:
 
-Installing your collection locally from a git repository
+Installing your collection locally from a Git repository
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-To install your collection locally from a git repository, specify the repository and the branch you want to install:
+To install your collection locally from a Git repository, specify the repository and the branch you want to install:
 
 .. code-block:: bash
 
diff --git a/docs/docsite/rst/dev_guide/developing_collections_shared.rst b/docs/docsite/rst/dev_guide/developing_collections_shared.rst
@@ -72,15 +72,15 @@ Listing collection dependencies
 
 We recommend that collections work as standalone, independent units, depending only on ansible-core. However, if your collection must depend on features and functionality from another collection, list the other collection or collections under ``dependencies`` in your collection's :file:`galaxy.yml` file. Use the :file:`meta/runtime.yml` file to set the ansible-core version that your collection depends on. For more information on the :file:`galaxy.yml` file, see :ref:`collections_galaxy_meta`.
 
-You can use git repositories for collection dependencies during local development and testing. For example:
+You can use Git repositories for collection dependencies during local development and testing. For example:
 
 .. code-block:: yaml
 
    dependencies: {'git@github.com:organization/repo_name.git': 'devel'}
 
 .. warning::
 
-   Do not use git repositories as dependencies for published collections. Dependencies for published collections must be other published collections.
+   Do not use Git repositories as dependencies for published collections. Dependencies for published collections must be other published collections.
 
 .. seealso::
 
diff --git a/docs/docsite/rst/dev_guide/developing_collections_structure.rst b/docs/docsite/rst/dev_guide/developing_collections_structure.rst
@@ -204,7 +204,7 @@ Ansible Collections are tested much like Ansible itself, by using the `ansible-t
 
 See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``.
 
-When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code through a git clone, which is typical of an Ansible developer. However, it is not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you.
+When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code through a Git clone, which is typical of an Ansible developer. However, it is not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you.
 
 
 meta directory
diff --git a/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst b/docs/docsite/rst/dev_guide/developing_modules_in_groups.rst
@@ -64,7 +64,7 @@ Your collection should include the following files to be usable:
 
 When you have these files ready, review the :ref:`developing_modules_checklist` again. If you are creating a new collection, you are responsible for all procedures related to your repository, including setting rules for contributions, finding reviewers, and testing and maintaining the code in your collection.
 
-New to git or GitHub
+New to Git or GitHub
 ====================
 
 We realize this may be your first use of Git or GitHub. The following guides may be of use:
diff --git a/docs/docsite/rst/dev_guide/developing_rebasing.rst b/docs/docsite/rst/dev_guide/developing_rebasing.rst
@@ -77,7 +77,7 @@ Updating your pull request
 
 Now that you've rebased your branch, you need to push your changes to GitHub to update your PR.
 
-Since rebasing re-writes git history, you will need to use a force push:
+Since rebasing re-writes Git history, you will need to use a force push:
 
 .. code-block:: shell-session
 
diff --git a/docs/docsite/rst/dev_guide/testing.rst b/docs/docsite/rst/dev_guide/testing.rst
@@ -80,7 +80,7 @@ Rerunning a failing CI job
 
 Occasionally you may find your PR fails due to a reason unrelated to your change. This could happen for several reasons, including:
 
-* a temporary issue accessing an external resource, such as a yum or git repo
+* a temporary issue accessing an external resource, such as a yum or Git repo
 * a timeout creating a virtual machine to run the tests on
 
 If either issue appears to be the case, you can rerun the Azure Pipelines test by:
@@ -152,7 +152,7 @@ Use the pull request number when you fetch the proposed changes and create your
 The first command fetches the proposed changes from the pull request and creates a new branch named ``testing_PRXXXX``, where the XXXX is the actual number associated with the pull request (for example, 65381). The second command checks out the newly created branch.
 
 .. note::
-   If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor.
+   If the GitHub user interface shows that the pull request will not merge cleanly, we do not recommend proceeding if you are not somewhat familiar with Git and coding, as you will have to resolve a merge conflict. This is the responsibility of the original pull request contributor.
 
 .. note::
    Some users do not create feature branches, which can cause problems when they have multiple, unrelated commits in their version of ``devel``. If the source looks like ``someuser:devel``, make sure there is only one commit listed on the pull request.
diff --git a/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst b/docs/docsite/rst/dev_guide/testing/sanity/integration-aliases.rst
@@ -55,7 +55,7 @@ Some test dependencies are automatically discovered:
 Aliases can be used to declare dependencies that are not handled automatically:
 
 - ``needs/target/TARGET`` - Requires use of the test target ``TARGET``.
-- ``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the git root.
+- ``needs/file/PATH`` - Requires use of the file ``PATH`` relative to the Git root.
 
 Skipping
 --------
diff --git a/docs/docsite/rst/dev_guide/testing_httptester.rst b/docs/docsite/rst/dev_guide/testing_httptester.rst
@@ -9,7 +9,7 @@ httptester
 Overview
 ========
 
-``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as git or package repos) which, if temporarily unavailable, would cause tests to fail.
+``httptester`` is a docker container used to host certain resources required by :ref:`testing_integration`. This is to avoid CI tests requiring external resources (such as Git or package repos) which, if temporarily unavailable, would cause tests to fail.
 
 HTTP Testing endpoint which provides the following capabilities:
 
diff --git a/docs/docsite/rst/dev_guide/testing_integration.rst b/docs/docsite/rst/dev_guide/testing_integration.rst
@@ -58,7 +58,7 @@ files in the ``tests/integration/`` directory.
 Prerequisites
 =============
 
-Some tests assume things like hg, svn, and git are installed, and in path.  Some tests
+Some tests assume things like ``hg``, ``svn``, and ``git`` are installed, and in path.  Some tests
 (such as those for Amazon Web Services) need separate definitions, which will be covered
 later in this document.
 
diff --git a/docs/docsite/rst/dev_guide/testing_running_locally.rst b/docs/docsite/rst/dev_guide/testing_running_locally.rst
@@ -27,7 +27,7 @@ Before running ``ansible-test``, set up your environment for :ref:`testing_an_an
 Testing an Ansible Collection
 -----------------------------
 
-If you are testing an Ansible Collection, you need a copy of the collection, preferably a git clone.
+If you are testing an Ansible Collection, you need a copy of the collection, preferably a Git clone.
 For example, to work with the ``community.windows`` collection, follow these steps:
 
 1. Clone the collection you want to test into a valid collection root:
@@ -67,7 +67,7 @@ For example, to work with the ``community.windows`` collection, follow these ste
 Testing ``ansible-core``
 ------------------------
 
-If you are testing ``ansible-core`` itself, you need a copy of the ``ansible-core`` source code, preferably a git clone.
+If you are testing ``ansible-core`` itself, you need a copy of the ``ansible-core`` source code, preferably a Git clone.
 Having an installed copy of ``ansible-core`` is not sufficient or required.
 For example, to work with the ``ansible-core`` source cloned from GitHub, follow these steps:
 
diff --git a/docs/docsite/rst/galaxy/user_guide.rst b/docs/docsite/rst/galaxy/user_guide.rst
@@ -108,7 +108,7 @@ This returns everything found in Galaxy for the role:
 Installing roles from Galaxy
 ============================
 
-The ``ansible-galaxy`` command comes bundled with Ansible, and you can use it to install roles from Galaxy or directly from a git based SCM. You can
+The ``ansible-galaxy`` command comes bundled with Ansible, and you can use it to install roles from Galaxy or directly from a Git based SCM. You can
 also use it to create a new role, remove roles, or perform tasks on the Galaxy website.
 
 The command line tool by default communicates with the Galaxy website API using the server address *https://galaxy.ansible.com*. If you run your own internal Galaxy server
@@ -150,7 +150,7 @@ The following provides an example of using ``--roles-path`` to install the role
 Installing a specific version of a role
 ---------------------------------------
 
-When the Galaxy server imports a role, it imports any git tags matching the `Semantic Version <https://semver.org/>`_ format as versions.
+When the Galaxy server imports a role, it imports any Git tags matching the `Semantic Version <https://semver.org/>`_ format as versions.
 In turn, you can download a specific version of a role by specifying one of the imported tags.
 
 To see the available versions for a role:
@@ -165,7 +165,7 @@ To install a specific version of a role from Galaxy, append a comma and the valu
 
    $ ansible-galaxy role install geerlingguy.apache,3.2.0
 
-It is also possible to point directly to the git repository and specify a branch name or commit hash as the version. For example, the following will
+It is also possible to point directly to the Git repository and specify a branch name or commit hash as the version. For example, the following will
 install a specific commit:
 
 .. code-block:: bash
@@ -191,7 +191,7 @@ Each role in the file will have one or more of the following attributes:
 
    src
      The source of the role. Use the format *namespace.role_name*, if downloading from Galaxy; otherwise, provide a URL pointing
-     to a repository within a git based SCM. See the examples below. This is a required attribute.
+     to a repository within a Git based SCM. See the examples below. This is a required attribute.
    scm
      Specify the SCM. As of this writing only *git* or *hg* are allowed. See the examples below. Defaults to *git*.
    version:
@@ -207,7 +207,7 @@ Use the following example as a guide for specifying roles in *requirements.yml*:
     # from galaxy
     - name: yatesr.timezone
 
-    # from locally cloned git repository (git+file:// requires full paths)
+    # from locally cloned Git repository (git+file:// requires full paths)
     - src: git+file:///home/bennojoy/nginx
 
     # from GitHub
diff --git a/docs/docsite/rst/inventory_guide/connection_details.rst b/docs/docsite/rst/inventory_guide/connection_details.rst
diff --git a/docs/docsite/rst/inventory_guide/intro_inventory.rst b/docs/docsite/rst/inventory_guide/intro_inventory.rst
diff --git a/docs/docsite/rst/reference_appendices/faq.rst b/docs/docsite/rst/reference_appendices/faq.rst
diff --git a/docs/docsite/rst/reference_appendices/glossary.rst b/docs/docsite/rst/reference_appendices/glossary.rst
diff --git a/hacking/README.md b/hacking/README.md
diff --git a/hacking/ticket_stubs/README.md b/hacking/ticket_stubs/README.md
