Remove wordy phrases from Source Code pages

doc/administration/git_protocol.md

@@ -10,8 +10,8 @@ description: "Set and configure Git protocol v2"
 > [Re-enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/27828) in GitLab 12.8.
 
 Git protocol v2 improves the v1 wire protocol in several ways and is
-enabled by default in GitLab for HTTP requests. In order to enable SSH,
-further configuration is needed by the administrator.
+enabled by default in GitLab for HTTP requests. To enable SSH, additional
+configuration is required by an administrator.
 
 More details about the new features and improvements are available in
 the [Google Open Source Blog](https://opensource.googleblog.com/2018/05/introducing-git-protocol-version-2.html)
@@ -48,7 +48,7 @@ sudo systemctl restart ssh
 
 ## Instructions
 
-In order to use the new protocol, clients need to either pass the configuration
+To use the new protocol, clients need to either pass the configuration
 `-c protocol.version=2` to the Git command, or set it globally:
 
 ```shell

doc/api/commits.md

 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments"
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Commits API **(FREE)**
@@ -502,9 +502,8 @@ Example response:
 
 Adds a comment to a commit.
 
-In order to post a comment in a particular line of a particular file, you must
-specify the full commit SHA, the `path`, the `line` and `line_type` should be
-`new`.
+To post a comment in a particular line of a particular file, you must specify
+the full commit SHA, the `path`, the `line`, and `line_type` should be `new`.
 
 The comment is added at the end of the last commit if at least one of the
 cases below is valid:

doc/gitlab-basics/command-line-commands.md

 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments"
-type: howto, reference
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 ---
 
 # Edit files through the command line **(FREE)**
 
 When [working with Git from the command line](start-using-git.md), you need to
 use more than just the Git commands. There are several basic commands that you should
-learn, in order to make full use of the command line.
+learn to make full use of the command line.
 
 ## Start working on your project
 

doc/topics/gitlab_flow.md

 ---
 stage: Create
 group: Source Code
-info: "To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments"
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
 disqus_identifier: 'https://docs.gitlab.com/ee/workflow/gitlab_flow.html'
 ---
 
@@ -47,9 +47,11 @@ For a video introduction of how this works in GitLab, see [GitLab Flow](https://
 
 <!-- vale gitlab.Spelling = YES -->
 
-Git flow was one of the first proposals to use Git branches, and it has received a lot of attention.
-It suggests a `main` branch and a separate `develop` branch, as well as supporting branches for features, releases, and hotfixes.
-The development happens on the `develop` branch, moves to a release branch, and is finally merged into the `main` branch.
+Git flow was one of the first proposals to use Git branches, and it has received
+a lot of attention. It suggests a `main` branch and a separate `develop` branch,
+with supporting branches for features, releases, and hotfixes. The development
+happens on the `develop` branch, moves to a release branch, and is finally merged
+into the `main` branch.
 
 Git flow is a well-defined standard, but its complexity introduces two problems.
 The first problem is that developers must use the `develop` branch and not `main`. `main` is reserved for code that is released to production.

doc/user/project/badges.md

@@ -84,7 +84,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
+Both the URL a badge points to and the image URL can contain placeholders
 which are evaluated when displaying the badge. The following placeholders
 are available:
 

doc/user/project/merge_requests/squash_and_merge.md

@@ -2,13 +2,10 @@
 stage: Create
 group: Source Code
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
-type: reference, concepts
 ---
 
 # Squash and merge **(FREE)**
 
-> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/18956) from GitLab Premium to GitLab Free in 11.0.
-
 With squash and merge you can combine all your merge request's commits into one
 and retain a clean history.
 
@@ -75,7 +72,7 @@ can be either selected or unselected:
 
 ![Squash commits checkbox on accept merge request form](img/squash_mr_widget.png)
 
-Note that Squash and Merge might not be available depending on the project's configuration
+Squash and Merge might not be available depending on the project's configuration
 for [Squash Commit Options](#squash-commits-options).
 
 ## Commit metadata for squashed commits
@@ -88,9 +85,9 @@ The squashed commit has the following metadata:
 
 ## Squash and fast-forward merge
 
-When a project has the [fast-forward merge setting enabled](fast_forward_merge.md#enabling-fast-forward-merges), the merge
-request must be able to be fast-forwarded without squashing in order to squash
-it. This is because squashing is only available when accepting a merge request,
+When a project has the [fast-forward merge setting enabled](fast_forward_merge.md#enabling-fast-forward-merges),
+the merge request must be able to be fast-forwarded without squashing to squash
+it. This is because squashing is available only when accepting a merge request,
 so a merge request may need to be rebased before squashing, even though
 squashing can itself be considered equivalent to rebasing.