Merge branch 'docs-aqualls-create-future-tense2' into 'master'

More cleanup of future tense, Create

See merge request gitlab-org/gitlab!55882

doc/user/project/badges.md

@@ -19,7 +19,7 @@ project maintainers.
 
 ## Project badges
 
-Badges can be added to a project by Maintainers or Owners, and will then be visible on the project's overview page.
+Badges can be added to a project by Maintainers or Owners, and are visible on the project's overview page.
 If you find that you have to add the same badges to several projects, you may want to add them at the [group level](#group-badges).
 
 To add a new badge to a project:
@@ -52,7 +52,7 @@ To add this badge to a project:
 
 ## Group badges
 
-Badges can be added to a group and will then be visible on every project's
+Badges can be added to a group and are visible on every project's
 overview page that's under that group. In this case, they cannot be edited or
 deleted on the project level. If you need to have individual badges for each
 project, consider adding them on the [project level](#project-badges) or use
@@ -75,7 +75,7 @@ Badges directly associated with a project can be configured on the
 ## Placeholders
 
 The URL a badge points to, as well as the image URL, can contain placeholders
-which will be evaluated when displaying the badge. The following placeholders
+which are evaluated when displaying the badge. The following placeholders
 are available:
 
 - `%{project_path}`: Path of a project including the parent groups

doc/user/project/push_options.md

@@ -66,7 +66,7 @@ time as pushing changes:
 | `merge_request.remove_source_branch`         | Set the merge request to remove the source branch when it's merged.                                             | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64320)          |
 | `merge_request.title="<title>"`              | Set the title of the merge request. Ex: `git push -o merge_request.title="The title I want"`.                   | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64320)          |
 | `merge_request.description="<description>"`  | Set the description of the merge request. Ex: `git push -o merge_request.description="The description I want"`. | [12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/64320)          |
-| `merge_request.label="<label>"`              | Add labels to the merge request. If the label does not exist, it will be created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31831) |
+| `merge_request.label="<label>"`              | Add labels to the merge request. If the label does not exist, it is created. For example, for two labels: `git push -o merge_request.label="label1" -o merge_request.label="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31831) |
 | `merge_request.unlabel="<label>"`            | Remove labels from the merge request. For example, for two labels: `git push -o merge_request.unlabel="label1" -o merge_request.unlabel="label2"`. | [12.3](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/31831) |
 
 If you use a push option that requires text with spaces in it, you need to enclose it
@@ -108,7 +108,7 @@ option](#push-options-for-merge-requests):
 git config --global alias.mwps "push -o merge_request.create -o merge_request.target=master -o merge_request.merge_when_pipeline_succeeds"
 ```
 
-Then to quickly push a local branch that will target master and merge when the
+Then to quickly push a local branch that targets the default branch and merges when the
 pipeline succeeds:
 
 ```shell

doc/user/project/repository/forking_workflow.md

@@ -31,25 +31,25 @@ Forking a project is, in most cases, a two-step process.
 
    ![Choose namespace](img/forking_workflow_choose_namespace_v13_2.png)
 
-The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
+The fork is created. The permissions you have in the namespace are your permissions in the fork.
 
 WARNING:
-When a public project with the repository feature set to "Members
-only" is forked, the repository will be public in the fork. The owner
-of the fork will need to manually change the visibility. This is being
+When a public project with the repository feature set to **Members Only**
+is forked, the repository is public in the fork. The owner
+of the fork must manually change the visibility. This is being
 fixed in [#36662](https://gitlab.com/gitlab-org/gitlab/-/issues/36662).
 
 ## Repository mirroring
 
 You can use [repository mirroring](repository_mirroring.md) to keep your fork synced with the original repository. You can also use `git remote add upstream` to achieve the same result.
 
-The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
+The main difference is that with repository mirroring, your remote fork is automatically kept up-to-date.
 
-Without mirroring, to work locally you'll have to use `git pull` to update your local repository
+Without mirroring, to work locally you must use `git pull` to update your local repository
 with the upstream project, then push the changes back to your fork to update it.
 
 WARNING:
-With mirroring, before approving a merge request, you'll likely be asked to sync; hence automating it is recommended.
+With mirroring, before approving a merge request, you are asked to sync. Because of this, automating it is recommended.
 
 Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).
 
@@ -60,7 +60,7 @@ When you are ready to send your code back to the upstream project,
 choose your forked project's branch. For **Target branch**, choose the original project's branch.
 
 NOTE:
-When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch will default to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
+When creating a merge request, if the forked project's visibility is more restrictive than the parent project (for example the fork is private, the parent is public), the target branch defaults to the forked project's default branch. This prevents potentially exposing the private code of the forked project.
 
 ![Selecting branches](img/forking_workflow_branch_select.png)
 

doc/user/project/repository/git_history.md

@@ -17,13 +17,12 @@ You can find the **History** button with each file in a project.
 
 ![File history button](img/file_history_button_v12_6.png "History button")
 
-When you select the **History** button, you'll see a screen with the
-noted information:
+When you select the **History** button, this information displays:
 
 ![Git log output](img/file_history_output_v12_6.png "History button output")
 
-If you hover over a commit in the UI, you'll see a precise date and time
-that commit was last modified.
+If you hover over a commit in the UI, the precise date and time of the commit modification
+are shown.
 
 ## Associated `git` command
 
@@ -36,7 +35,7 @@ following command:
 git log README.md
 ```
 
-You'll see output similar to the following, which includes the commit
+Git displays output similar to the following, which includes the commit
 time in UTC format:
 
 ```shell

doc/user/project/repository/gpg_signed_commits/index.md

@@ -40,7 +40,7 @@ For a commit to be verified by GitLab:
 
 ## Generating a GPG key
 
-If you don't already have a GPG key, the following steps will help you get
+If you don't already have a GPG key, the following steps can help you get
 started:
 
 1. [Install GPG](https://www.gnupg.org/download/index.html) for your operating system.
@@ -225,8 +225,8 @@ git config --global commit.gpgsign true
 ## Verifying commits
 
 1. Within a project or [merge request](../../merge_requests/index.md), navigate to
-   the **Commits** tab. Signed commits will show a badge containing either
-   "Verified" or "Unverified", depending on the verification status of the GPG
+   the **Commits** tab. Signed commits show a badge containing either
+   **Verified** or **Unverified**, depending on the verification status of the GPG
    signature.
 
    ![Signed and unsigned commits](img/project_signed_and_unsigned_commits.png)
@@ -240,8 +240,8 @@ git config --global commit.gpgsign true
 ## Revoking a GPG key
 
 Revoking a key **unverifies** already signed commits. Commits that were
-verified by using this key will change to an unverified state. Future commits
-will also stay unverified once you revoke this key. This action should be used
+verified by using this key changes to an unverified state. Future commits
+stay unverified after you revoke this key. This action should be used
 in case your key has been compromised.
 
 To revoke a GPG key:

doc/user/project/repository/x509_signed_commits/index.md

@@ -39,7 +39,7 @@ recommend using certificates from a PKI that are in line with
 
 ## Obtaining an X.509 key pair
 
-If your organization has Public Key Infrastructure (PKI), that PKI will provide
+If your organization has Public Key Infrastructure (PKI), that PKI provides
 an S/MIME key.
 
 If you do not have an S/MIME key pair from a PKI, you can either create your
@@ -49,7 +49,7 @@ and some of them generate keys for free.
 
 ## Associating your X.509 certificate with Git
 
-To take advantage of X.509 signing, you will need Git 2.19.0 or later. You can
+To take advantage of X.509 signing, you need Git 2.19.0 or later. You can
 check your Git version with:
 
 ```shell