Fix broken links

Author: fujii

docs/Deep Dive/GitHub/Git_Config.md

@@ -6,7 +6,7 @@ The WebKit project outlines a simplified recommended setup. This section outline
 
 ### Forking
 
-Since `git` is a decentralized version control system, a local copy can work with any remote that has the same set of shas. GitHub pull requests take advantage of this. After running [`git-webkit setup`](/WebKit/WebKit/wiki/Contributing#setup), the `.git/config` in the local WebKit repository should look something like this:
+Since `git` is a decentralized version control system, a local copy can work with any remote that has the same set of shas. GitHub pull requests take advantage of this. After running [`git-webkit setup`](/Getting Started/ContributingCode#getting-setup-to-contribute), the `.git/config` in the local WebKit repository should look something like this:
 
 ```
 [remote "origin"]
@@ -22,7 +22,7 @@ Since `git` is a decentralized version control system, a local copy can work wit
 
 Now, if a contributor runs `git push fork eng/some-branch`, `eng/some-branch` will be pushed to the remote `fork`, which should correspond to that contributor's personal fork of the WebKit project on GitHub. Likewise, running `git checkout remotes/fork/eng/some-branch` will checkout `eng/some-branch` according to that contributor's `fork` remote.
 
-[`git-webkit setup`](/WebKit/WebKit/wiki/Contributing#setup) also configures a remote with a contributors GitHub username. This is because if other contributors would like to checkout code from a pull request which they do not own, contributors will need to add this:
+[`git-webkit setup`](/Getting Started/ContributingCode#getting-setup-to-contribute) also configures a remote with a contributors GitHub username. This is because if other contributors would like to checkout code from a pull request which they do not own, contributors will need to add this:
 
 ```
 [remote "<username>"]
@@ -34,7 +34,7 @@ to their `.git/config` and run `git checkout remotes/<username>/eng/some-branch`
 
 ## Configuration Options
 
-[`git-webkit setup`](/WebKit/WebKit/wiki/Contributing#setup) automatically sets or prompts the contributor to define a number of `git` configuration options. Most contributors  should use the defaults recommended by [`git-webkit setup`](/WebKit/WebKit/wiki/Contributing#setup). This section defines, in detail, what an option does and why the WebKit project recommends a certain setting.
+[`git-webkit setup`](/Getting Started/ContributingCode#getting-setup-to-contribute) automatically sets or prompts the contributor to define a number of `git` configuration options. Most contributors  should use the defaults recommended by [`git-webkit setup`](/Getting Started/ContributingCode#getting-setup-to-contribute). This section defines, in detail, what an option does and why the WebKit project recommends a certain setting.
 
 ### user.email
 
@@ -46,7 +46,7 @@ Enter git user email for this repository:
 
 The `user.email` option is usually configured globally, and will become the contact information in `git` when authoring or committing a change. This is also the part of a commit that GitHub uses when attributing commits to specific users. The email a contributor defines here should be one of that contributor's emails in GitHub so that changes are correctly attributed to the contributor.
 
-The WebKit project asks contributors to define this value for their WebKit repository specifically because a contributor's reported email may change over time, and may even differ between machines. [`git-webkit setup`'s](/WebKit/WebKit/wiki/Contributing#setup) prompt is an effort to make contributors think about what their reported contact information for this specific checkout should be.
+The WebKit project asks contributors to define this value for their WebKit repository specifically because a contributor's reported email may change over time, and may even differ between machines. [`git-webkit setup`'s](/Getting Started/ContributingCode#getting-setup-to-contribute) prompt is an effort to make contributors think about what their reported contact information for this specific checkout should be.
 
 Note that the author and committer listed in a `git` commit can easily be spoofed, so `user.email` plays no part in authentication. It is strictly for communication to other contributors.
 
@@ -104,7 +104,7 @@ When creating or editing commit messages, `git` will invoke an external editor.
 
 ## WebKit Options
 
-[`git-webkit`] respects a few options that are specific to the `webkitscmpy` library. [`git-webkit setup`](/WebKit/WebKit/wiki/Contributing#setup) does automatically configure some of these, [`metadata/project_config`](/WebKit/WebKit/blob/main/metadata/project_config) also contains a few default values for the project.
+[`git-webkit`] respects a few options that are specific to the `webkitscmpy` library. [`git-webkit setup`](/Getting Started/ContributingCode#getting-setup-to-contribute) does automatically configure some of these, [`metadata/project_config`](/WebKit/WebKit/blob/main/metadata/project_config) also contains a few default values for the project.
 
 ### webkitscmpy.pull-request
 

docs/Deep Dive/GitHub/Migration.md

@@ -11,7 +11,7 @@ If you see something like:
 fatal: not a git repository (or any parent up to mount point /Volumes)
 Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
 ```
-you have a [Subversion checkout](/WebKit/WebKit/wiki/Migration#subversion) and need to migrate to a GitHub checkout.
+you have a [Subversion checkout](#subversion) and need to migrate to a GitHub checkout.
 
 If you see something like:
 ```
@@ -23,28 +23,28 @@ or:
 origin    https://git.webkit.org/git/WebKit (fetch)
 origin    https://git.webkit.org/git/WebKit (push)
 ```
-you have an [obsolete git mirror](/WebKit/WebKit/wiki/Migration#obsolete-mirror) for how to deal with patches uploaded to bugzilla.) and need to migrate to a GitHub checkout.
+you have an [obsolete git mirror](#obsolete-mirror) for how to deal with patches uploaded to bugzilla.) and need to migrate to a GitHub checkout.
 
 If you see something like:
 ```
 origin    [email protected]:WebKit/WebKit.git (fetch)
 origin    [email protected]:WebKit/WebKit.git (push)
 ```
-you already have a GitHub checkout, and can skip to [setting up your checkout](/WebKit/WebKit/wiki/Contributing#setup).
+you already have a GitHub checkout, and can skip to [setting up your checkout](/Getting Started/ContributingCode#getting-setup-to-contribute).
 
 ## Subversion
 
 Migrating from a Subversion checkout involves first cloning the WebKit repository with `git clone https://github.com/WebKit/WebKit.git <local path>`. A SSH based clone will work as well, but will require an [SSH key to be uploaded](https://github.com/settings/keys).
 
-After your clone completes, [set up your checkout](/WebKit/WebKit/wiki/Contributing#setup). If you don't have local changes in your Subversion checkout, no more migration work is required. If you do have local changes, use `Tools/Scripts/svn-create-patch` to save those changes in a local `.patch` file and then run `Tools/Scripts/svn-apply` to apply that patch to your new GitHub clone. See [below](/WebKit/WebKit/wiki/Migration#webkit-patch) for how to deal with patches uploaded to bugzilla.
+After your clone completes, [set up your checkout](/Getting Started/ContributingCode#getting-setup-to-contribute). If you don't have local changes in your Subversion checkout, no more migration work is required. If you do have local changes, use `Tools/Scripts/svn-create-patch` to save those changes in a local `.patch` file and then run `Tools/Scripts/svn-apply` to apply that patch to your new GitHub clone. See [below](#webkit-patch) for how to deal with patches uploaded to bugzilla.
 
 ## Obsolete Mirror
 
 The repository hosted via [github.com/WebKit/WebKit](https://github.com/WebKit/WebKit) has different commits from the ones hosted on [git.webkit.org](https://git.webkit.org). While it is possible convert an existing checkout, the WebKit team recomends that you freshly clone the WebKit repository with `git clone https://github.com/WebKit/WebKit.git <local path>`. A SSH based clone will work as well, but will require an [SSH key to be uploaded](https://github.com/settings/keys).
 
-After your clone completes, [set up your checkout](/WebKit/WebKit/wiki/Contributing#setup). The WebKit team has not built automation to assist in migrating branches from [git.webkit.org](https://git.webkit.org) checkouts to [github.com/WebKit/WebKit](https://github.com/WebKit/WebKit) ones. However, the content on disk in both repositories is identical. That means that something like `git -C <oldpath> diff HEAD~1 | git -C <newpath> apply` will apply a commit from one checkout to the other, assuming the diff of the commit you're moving applies to commit you have checked out.
+After your clone completes, [set up your checkout](/Getting Started/ContributingCode#getting-setup-to-contribute). The WebKit team has not built automation to assist in migrating branches from [git.webkit.org](https://git.webkit.org) checkouts to [github.com/WebKit/WebKit](https://github.com/WebKit/WebKit) ones. However, the content on disk in both repositories is identical. That means that something like `git -C <oldpath> diff HEAD~1 | git -C <newpath> apply` will apply a commit from one checkout to the other, assuming the diff of the commit you're moving applies to commit you have checked out.
 
-See [below](/WebKit/WebKit/wiki/Migration#webkit-patch) for how to deal with patches uploaded to bugzilla.
+See [below](#webkit-patch) for how to deal with patches uploaded to bugzilla.
 
 ## webkit-patch
 

docs/Deep Dive/GitHub/Pull_Requests.md

@@ -8,7 +8,7 @@ The first step of most pull requests is creating a [bug](https://bugs.webkit.org
 
 ## Branching
 
-Pull request branches are owned by their author, which is why `git-webkit setup` [creates a personal fork of WebKit](/WebKit/WebKit/wiki/Contributing#setup). This means that the WebKit project cannot enforce branching idioms, although there are some suggestions the WebKit team has so that other contributors can more easily access proposed changes. `Tools/Scripts/git-webkit pr` derives it's `eng` prefixed branch from the bug title of the bug associated with a pull request.
+Pull request branches are owned by their author, which is why `git-webkit setup` [creates a personal fork of WebKit](/Getting Started/ContributingCode#getting-setup-to-contribute). This means that the WebKit project cannot enforce branching idioms, although there are some suggestions the WebKit team has so that other contributors can more easily access proposed changes. `Tools/Scripts/git-webkit pr` derives it's `eng` prefixed branch from the bug title of the bug associated with a pull request.
 
 We suggest that pull request branch names are prefixed by `eng/` or `dev/` so that contributors are clear which branches contain production code when they add other user's forks as remotes. Notably, [EWS](https://ews-build.webkit.org) is unable to apply changes which come from the branch they are targeting (ie, [EWS](https://ews-build.webkit.org) cannot apply a change from `Contributor/WebKit:main` onto `WebKit/WebKit:main`), so in order to be reviewed, changes must come from a different branch.
 
@@ -22,18 +22,18 @@ The WebKit project heavily relies on commit messages to defend project performan
 * High level explanation (optional)
 * Files changes, what was changed, and why
 
-`git-webkit setup` [configures `.git/prepare-commit-msg`](/WebKit/WebKit/wiki/Contributing#setup) such that your commit message template is formatted to the standards of the WebKit project.
+`git-webkit setup` [configures `.git/prepare-commit-msg`](/Getting Started/ContributingCode#getting-setup-to-contribute) such that your commit message template is formatted to the standards of the WebKit project.
 
 In addition to pull request commits having verbose commit messages, the WebKit project also expects the content of commit messages in the pull request description. This is so that reviewers can provide feedback on the commit message itself.
 
 ## Reviewing
 
-Commits generally require the approval of a [reviewer](https://webkit.org/team/#reviewers), although there are narrow exceptions for test expectation gardening and build fixes. Reviewers will approve pull requests through the GitHub UI by marking pull requests as "Approved." Note that approval from someone who is not a reviewer will not be recognized by [Merge-Queue](/WebKit/WebKit/wiki/Contributing#merge-queue).
+Commits generally require the approval of a [reviewer](https://webkit.org/team/#reviewers), although there are narrow exceptions for test expectation gardening and build fixes. Reviewers will approve pull requests through the GitHub UI by marking pull requests as "Approved." Note that approval from someone who is not a reviewer will not be recognized by [Merge-Queue](/Getting Started/ContributingCode#merge-queue).
 
 ## Landing
 
-Only repository administers have direct commit access, and this is reserved for repairing infrastructure issues. Pull requests should be landed through [Merge-Queue](/WebKit/WebKit/wiki/Contributing#merge-queue), which is achieved by applying [`merge-queue`](https://github.com/WebKit/WebKit/labels?q=merge-queue) or [`unsafe-merge-queue`](https://github.com/WebKit/WebKit/labels?q=unfsafe-merge-queue) label to your pull request.
+Only repository administers have direct commit access, and this is reserved for repairing infrastructure issues. Pull requests should be landed through [Merge-Queue](/Getting Started/ContributingCode#merge-queue), which is achieved by applying [`merge-queue`](https://github.com/WebKit/WebKit/labels?q=merge-queue) or [`unsafe-merge-queue`](https://github.com/WebKit/WebKit/labels?q=unfsafe-merge-queue) label to your pull request.
 
-[Merge-Queue](/WebKit/WebKit/wiki/Contributing#merge-queue) will check to make sure a change is reviewed by adding the name of all [reviewers](https://webkit.org/team/#reviewers) who have approved a pull request to the commit message. [Merge-Queue](/WebKit/WebKit/wiki/Contributing#merge-queue) will then check the commit message for `Reviewed by`.
+[Merge-Queue](/Getting Started/ContributingCode#merge-queue) will check to make sure a change is reviewed by adding the name of all [reviewers](https://webkit.org/team/#reviewers) who have approved a pull request to the commit message. [Merge-Queue](/Getting Started/ContributingCode#merge-queue) will then check the commit message for `Reviewed by`.
 
-Note that [Merge-Queue](/WebKit/WebKit/wiki/Contributing#merge-queue) will reject pull requests that are labeled by contributors who are not [committers](https://webkit.org/team/#committers).
+Note that [Merge-Queue](/Getting Started/ContributingCode#merge-queue) will reject pull requests that are labeled by contributors who are not [committers](https://webkit.org/team/#committers).