Commit 828ec0b0 authored by Amy Qualls's avatar Amy Qualls Committed by Craig Norris

More cleanup of future tense, Create

Remove yet more future tense from the Source Code docs.
parent ae1def2e
......@@ -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
......
......@@ -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
......
......@@ -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)
......
......@@ -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
......
......@@ -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:
......
......@@ -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
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment