diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index be7da61176..75c8f4cf03 100644 --- 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 index 880f78de4a..7c346bbb88 100644 --- 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 index 0eae079863..1aaece95ee 100644 --- 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 index acd549632b..1784b702dd 100644 --- a/docs/docsite/rst/community/collection_contributors/collection_requirements.rst +++ b/docs/docsite/rst/community/collection_contributors/collection_requirements.rst @@ -375,7 +375,7 @@ 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. @@ -383,7 +383,7 @@ Repository management * 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 index aad80389ad..c830a0914e 100644 --- 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 `_ (rST). Some collection-level documentation is written in a subset of `Markdown `_. 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 `_ (rST). Some collection-level documentation is written in a subset of `Markdown `_. 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 index 09675502e4..62c001c3fe 100644 --- 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 `_ through the `Zuul dashboard `_. #. Final announcement. #. Optionally, `file a request to include a new collection into the Ansible package `_. diff --git a/docs/docsite/rst/community/other_tools_and_programs.rst b/docs/docsite/rst/community/other_tools_and_programs.rst index 82ab7a7d5c..68589bb5a2 100644 --- 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 `_ - shows information about files in a git repository. +* `GitGutter `_ - shows information about files in a Git repository. * `SideBarEnhancements `_ - provides enhancements to the operations on Sidebar of Files and Folders. * `Sublime Linter `_ - a code-linting framework for Sublime Text 3. * `Pretty YAML `_ - 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 index 5fc71fee8e..a1e2984b20 100644 --- 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 index ee70217730..af44d27369 100644 --- 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 `_ 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 `_ 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 index 167726dc48..1569d22f83 100644 --- 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 index baba942276..11da101d24 100644 --- a/docs/docsite/rst/dev_guide/developing_collections_shared.rst +++ b/docs/docsite/rst/dev_guide/developing_collections_shared.rst @@ -72,7 +72,7 @@ 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 @@ -80,7 +80,7 @@ You can use git repositories for collection dependencies during local developmen .. 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 index 6c15c31973..a75c4a7f29 100644 --- 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 index 8298f6c0d8..4eed09ada4 100644 --- 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 index e08ac451db..038f88eed9 100644 --- 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 index 51a37524fa..6e743a6f33 100644 --- 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 index bc97b2e3cd..02c7397847 100644 --- 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 index c9d364cf85..09f6fedbab 100644 --- 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 index e830ba032b..13988e0059 100644 --- 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 index 0d03189bf4..86fac4a62b 100644 --- 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 index 1caaef4f1c..fd447fa752 100644 --- 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 `_ format as versions. +When the Galaxy server imports a role, it imports any Git tags matching the `Semantic Version `_ 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 index 2c462e32b4..d7ef373449 100644 --- a/docs/docsite/rst/inventory_guide/connection_details.rst +++ b/docs/docsite/rst/inventory_guide/connection_details.rst @@ -120,4 +120,4 @@ Other connection methods ------------------------ Ansible can use a variety of connection methods beyond SSH. You can select any connection plugin, including managing things locally and managing chroot, lxc, and jail containers. -A mode called 'ansible-pull' can also invert the system and have systems 'phone home' with scheduled git checkouts to pull configuration directives from a central repository. +A mode called 'ansible-pull' can also invert the system and have systems 'phone home' with scheduled Git checkouts to pull configuration directives from a central repository. diff --git a/docs/docsite/rst/inventory_guide/intro_inventory.rst b/docs/docsite/rst/inventory_guide/intro_inventory.rst index 1e7286c603..11aa6cec56 100644 --- a/docs/docsite/rst/inventory_guide/intro_inventory.rst +++ b/docs/docsite/rst/inventory_guide/intro_inventory.rst @@ -508,7 +508,7 @@ file gets too big, or when you want to use :ref:`Ansible Vault` For ``ansible-playbook`` you can also add ``group_vars/`` and ``host_vars/`` directories to your playbook directory. Other Ansible commands (for example, ``ansible``, ``ansible-console``, and so on) will only look for ``group_vars/`` and ``host_vars/`` in the inventory directory. If you want other commands to load group and host variables from a playbook directory, you must provide the ``--playbook-dir`` option on the command line. If you load inventory files from both the playbook directory and the inventory directory, variables in the playbook directory will override variables set in the inventory directory. -Keeping your inventory file and variables in a git repo (or other version control) +Keeping your inventory file and variables in a Git repo (or other version control) is an excellent way to track changes to your inventory and host variables. .. _how_we_merge: diff --git a/docs/docsite/rst/reference_appendices/faq.rst b/docs/docsite/rst/reference_appendices/faq.rst index eb985bd21f..3e11695088 100644 --- a/docs/docsite/rst/reference_appendices/faq.rst +++ b/docs/docsite/rst/reference_appendices/faq.rst @@ -379,7 +379,7 @@ What is the best way to make content reusable/redistributable? ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ If you have not done so already, read all about "Roles" in the playbooks documentation. This helps you make playbook content -self-contained, and works well with things like git submodules for sharing content with others. +self-contained, and works well with things like Git submodules for sharing content with others. If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended. @@ -906,7 +906,7 @@ The native jinja2 functionality actually allows us to return full Python objects How do I submit a change to the documentation? ++++++++++++++++++++++++++++++++++++++++++++++ -Documentation for Ansible is kept in the main project git repository, and complete instructions +Documentation for Ansible is kept in the main project Git repository, and complete instructions for contributing can be found in the docs README `viewable on GitHub `_. Thanks! diff --git a/docs/docsite/rst/reference_appendices/glossary.rst b/docs/docsite/rst/reference_appendices/glossary.rst index dbe442a8ef..361a2c87d6 100644 --- a/docs/docsite/rst/reference_appendices/glossary.rst +++ b/docs/docsite/rst/reference_appendices/glossary.rst @@ -383,7 +383,7 @@ when a term comes up on the :ref:`Ansible Forum`. choices. :command:`ansible-pull` works by checking configuration orders out of - git on a crontab and then managing the machine locally, using the + Git on a crontab and then managing the machine locally, using the :term:`local connection` plugin. Pulp 3 Galaxy diff --git a/hacking/README.md b/hacking/README.md index 03c0868676..2da6c9fccb 100644 --- a/hacking/README.md +++ b/hacking/README.md @@ -5,7 +5,7 @@ env-setup --------- The 'env-setup' script modifies your environment to allow you to run -ansible from a git checkout using python >= 3.8. +ansible from a Git checkout using Python >= 3.8. First, set up your environment to run from the checkout: diff --git a/hacking/ticket_stubs/README.md b/hacking/ticket_stubs/README.md index 2ab983f76a..0c6e0f036b 100644 --- a/hacking/ticket_stubs/README.md +++ b/hacking/ticket_stubs/README.md @@ -3,4 +3,4 @@ What's this? This is a directory of common responses to save some typing when responding to GitHub tickets to avoid some carpal tunnel syndrome events as Ansible maintainers deal with the ticket influx. -They are present in the project git repo (on GitHub) so it's easy for people to share and update these snippets of text. +They are present in the project Git repo (on GitHub) so it's easy for people to share and update these snippets of text.