website: use root-relative links to workaround Docusaurs issues

Summary:
Docusaurs has a buggy behavior that relative links are unreliable:
- New tab. Open page URL https://sapling-scm.com/docs/git/intro/. click links
  like "Git support modes". It goes to https://sapling-scm.com/docs/git/intro/git_support_modes which is not found.
- New tab. Open page URL https://sapling-scm.com/. Click "Documentation" >
  "Git Interop" > "Introduction" > "Git support modes". It works as expected.

A script is added to run this codemod.

Reviewed By: evangrayk

Differential Revision: D66889420

fbshipit-source-id: fbacd5bc59547ed0db6ca1c031ca765e707e0c2a

website/docs/addons/isl.md

@@ -51,7 +51,7 @@ You can drag and drop commits to rebase them. This is the easiest way to re-arra
 Note that drag-and-drop rebasing is not allowed while you have uncommitted changes, since it's harder to deal with merge conflicts.
 Commit any uncommitted changes first to work around this.
 
-Drag-and-drop performs a <Command name="rebase" linkText="sl rebase" />, including all commits stacked on top of the commit being dragged. If you want to re-arrange commits within your stack, consider using [`sl histedit`](../commands/histedit.md).
+Drag-and-drop performs a <Command name="rebase" linkText="sl rebase" />, including all commits stacked on top of the commit being dragged. If you want to re-arrange commits within your stack, consider using [`sl histedit`](/docs/commands/histedit.md).
 
 
 ### Running commands
@@ -95,7 +95,7 @@ let you create or amend your commit using your message.
 
 :::tip
 
-In order to interact with GitHub for code review in ISL, be sure to install the `gh` GitHub CLI. [Learn more.](../git/intro.md)
+In order to interact with GitHub for code review in ISL, be sure to install the `gh` GitHub CLI. [Learn more.](/docs/git/intro.md)
 
 :::
 
@@ -111,12 +111,12 @@ ISL will prompt you for your choice the first time you try to submit. This can a
 sl config --local github.preferred_submit_command <ghstack or pr>
 ```
 
-See documentation on [Using Sapling with GitHub](../git/intro.md) for more information.
+See documentation on [Using Sapling with GitHub](/docs/git/intro.md) for more information.
 
 <ThemedImage alt="Pull Request Badges" light="/img/isl/pr_light.png" dark="/img/isl/pr_dark.png" />
 
 Commits in your tree which are associated with a GitHub Pull Request will show a badge underneath showing the status of that Pull Request.
-You can click this badge to open the Pull Request in GitHub (or [configure it to open alternate domains](../introduction/getting-started#browsing-pull-requests)).
+You can click this badge to open the Pull Request in GitHub (or [configure it to open alternate domains](/docs/introduction/getting-started.md#browsing-pull-requests)).
 
 This badge also shows the CI build status and how many comments there are.
 

website/docs/addons/vscode.md

@@ -15,15 +15,15 @@ Sapling provides an extension for [Visual Studio Code](https://code.visualstudio
 Sapling must be installed through the normal installation instructions in order for
 the VS Code extension to work properly.
 
-[See installation instructions.](../introduction/installation.md)
+[See installation instructions.](/docs/introduction/installation.md)
 
 :::
 
 <ThemedImage alt="ISL in VS Code" light="/img/isl/vscode_light.png" dark="/img/isl/vscode_dark.png" />
 
 
 ### Embedded interactive smartlog
-Access the [Interactive Smartlog (ISL)](./isl.md) interface directly within VS Code,
+Access the [Interactive Smartlog (ISL)](/docs/addons/isl.md) interface directly within VS Code,
 without needing to launch it with <SLCommand name="web" />.
 Just run the **Sapling: Open Interactive Smartlog** command from the [command palette](https://code.visualstudio.com/docs/getstarted/userinterface#_command-palette).
 

website/docs/commands/sl.md

@@ -13,7 +13,7 @@ show a graph of the commits that are relevant to you
 
 `sl` is a built-in alias for `smartlog -T {sl}`
 
-[Smartlog](../overview/smartlog) is one of most important features in Sapling, it provides
+[Smartlog](/docs/overview/smartlog.md) is one of most important features in Sapling, it provides
 you with a succinct view of your work by hiding all commits that aren’t relevant to you.
 
 

website/docs/dev/internals/internal-difference-hg.md

@@ -11,7 +11,7 @@ Mercurial treats all commits as visible by default, using obsolescence data to
 mark obsoleted commits as invisible.
 
 Sapling treats all commits as invisible by default, using ["visible
-heads"](./visibility-and-mutation#commit-visibility)
+heads"](/docs/dev/internals/visibility-and-mutation.md#commit-visibility)
 and bookmark references to mark commits and their ancestors as visible. This
 is similar to Git.
 
@@ -47,7 +47,7 @@ there are no "visible secret" commits.
 ## Obsolescence
 
 Mercurial uses the "obsstore" to track commit rewrites. Sapling uses
-["mutation"](./visibility-and-mutation#commit-mutation). Their differences are:
+["mutation"](/docs/dev/internals/visibility-and-mutation.md#commit-mutation). Their differences are:
 - Obsstore decides visibility. Mutation does not decide visibility.
 - Obsstore supports "prune" operation to remove a commit without a successor
   commit. Mutation requires at least one successor commit so it cannot track
@@ -64,15 +64,15 @@ Sapling requires `O(N)` loading of the entire mutation data.
 ## Storage format
 
 Mercurial uses [Revlog](https://www.mercurial-scm.org/wiki/Revlog) as its main
-file format. Sapling uses [IndexedLog](./indexedlog) instead.
+file format. Sapling uses [IndexedLog](/docs/dev/internals/indexedlog.md) instead.
 
 For working copy state, Mercurial uses [Dirstate](https://www.mercurial-scm.org/wiki/DirState).
 Sapling switched to TreeState in 2017. Mercurial 5.9 released in 2021
 introduced [Dirstate v2](https://www.mercurial-scm.org/repo/hg/file/tip/mercurial/helptext/internals/dirstate-v2.txt)
 that improves performance in a similar way.
 
 For repo references such as bookmarks and remote bookmarks, Mercurial tracks
-them in individual files like `.hg/bookmarks`. Sapling uses [MetaLog](./metalog)
+them in individual files like `.hg/bookmarks`. Sapling uses [MetaLog](/docs/dev/internals/metalog.md)
 to track them so changes across state files are atomic.
 
 

website/docs/dev/internals/metalog.md

@@ -22,7 +22,7 @@ data to answer questions like how and when bookmarks changed, etc.
 ### Structure
 
 MetaLog maintains 2 structures:
-- A blob store backed by [ZStore](./zstdelta#zstore). Blobs are keyed by their
+- A blob store backed by [ZStore](/docs/dev/internals/zstdelta.md#zstore). Blobs are keyed by their
   content SHA1s. There are 2 kinds of blobs: root, and content.
 - A log of keys of roots. It provides a way to get the latest root, and also
   historical roots.
@@ -37,7 +37,7 @@ itself. That is part of the reason for the naming.
 
 ### Concurrent writes
 
-Similar to [IndexedLog](./indexedlog#concurrent-writes), changes are buffered
+Similar to [IndexedLog](/docs/dev/internals/indexedlog.md#concurrent-writes), changes are buffered
 in memory until an explicit flush to disk.
 
 Unlike IndexedLog, if MetaLog notices that the latest root is changed on disk,

website/docs/dev/internals/zstdelta.md

@@ -25,5 +25,5 @@ In Python, `bindings.zstd` provides access to the `diff` and `apply` functions:
 
 The `zstore` Rust library provides an on-disk content store with internal
 delta-chain management. It uses the above `zstdelta` library for delta
-calculation and [IndexedLog](./indexedlog) for on-disk storage. It is used by
-[MetaLog](./metalog).
+calculation and [IndexedLog](/docs/dev/internals/indexedlog.md) for on-disk storage. It is used by
+[MetaLog](/docs/dev/internals/metalog.md).

website/docs/dev/process/writing_tests.md

@@ -153,7 +153,7 @@ interesting to the test. It will make deprecation of those features easier.
 ``hg debugdrawdag`` (or ``drawdag`` defined in ``tinit.sh``) can be used to
 create commits in a more readable, and efficient way. `newclientrepo` (also
 defined on `tinit.sh`) can also take the same input as `drawdag`. See
-[the drawdag page](../internals/drawdag) for more info.
+[the drawdag page](/docs/dev/internals/drawdag.md) for more info.
 
 #### Avoid depending on context
 

website/docs/git/git_support_modes.md

@@ -12,8 +12,8 @@ Sapling supports Git in 2 modes. Here is a quick comparison:
 | Repo directory | `.git` | `.sl` |
 | `git` commands | ✅ Supported | ⚠️ Not supported |
 | [Git LFS](https://git-lfs.com/) | Partially supported [^1] | ⚠️ Not supported |
-| Submodules | Work-In-Progress | [Supported without EdenFS](submodule) |
-| [ISL](../addons/isl) (graphic interface) | ✅ Supported | ✅ Supported |
+| Submodules | Work-In-Progress | [Supported without EdenFS](/docs/git/submodule.md) |
+| [ISL](/docs/addons/isl.md) (graphic interface) | ✅ Supported | ✅ Supported |
 | EdenFS (virtual filesystem) | ⚠️ Not supported | ✅ Supported (experimental [^2]) |
 | Git network protocol (Git or Mononoke server) | ✅ Supported | ✅ Supported |
 | Sapling network protocol (Mononoke server) | ⚠️ Not supported | ✅ Supported (experimental [^2]) |
@@ -24,7 +24,7 @@ Sapling supports Git in 2 modes. Here is a quick comparison:
 
 ## `.git` mode
 
-In this mode, Sapling tries to be compatible with `.git/` file formats so you can run `git` commands. For features not natively supported by Git like [mutation](../dev/internals/visibility-and-mutation#commit-mutation), Sapling will store them in the `.git/sl` directory.
+In this mode, Sapling tries to be compatible with `.git/` file formats so you can run `git` commands. For features not natively supported by Git like [mutation](/docs/dev/internals/visibility-and-mutation.md#commit-mutation), Sapling will store them in the `.git/sl` directory.
 
 There are some caveats using the `.git` mode:
 
@@ -49,5 +49,5 @@ For the working copy implementation, Sapling can use its own implementations:
 
 For server protocols, Sapling can use dedicated lazy commit graph protocols so `clone` and `pull` are roughly O(merges) both in time and space usage.
 
-For local storage, Sapling can use its [own structure](../dev/internals/indexedlog) and [compression](../dev/internals/zstdelta) so the file count is bounded and there is no need to repack. Note: This is not fully implemented for the git format yet but is the direction we'd like to go.
+For local storage, Sapling can use its [own structure](/docs/dev/internals/indexedlog.md) and [compression](/docs/dev/internals/zstdelta.md) so the file count is bounded and there is no need to repack. Note: This is not fully implemented for the git format yet but is the direction we'd like to go.
 

website/docs/git/github.md

@@ -11,7 +11,7 @@ When using Sapling with GitHub, we **strongly** recommend the following:
 
 In order for Sapling to work with GitHub pull requests on your behalf, you must provide it with a [Personal Access Token (PAT)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token). While the GitHub CLI is not the only way to obtain a PAT, it is certainly one of the most convenient.
 
-While we ultimately plan to remove the requirement of installing the GitHub CLI to use Sapling with GitHub (though the PAT will still be necessary), you will still need some mechanism to cache your GitHub credentials in Git to enjoy the best experience with Sapling. For example, a graphical interface like [Interactive Smartlog](../addons/isl.md) would be unpleasant to use if it prompted your for a password every time it needed to talk to GitHub. To avoid this, [GitHub recommends two solutions for caching your GitHub credentials](https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git), the GitHub CLI being the primary choice.
+While we ultimately plan to remove the requirement of installing the GitHub CLI to use Sapling with GitHub (though the PAT will still be necessary), you will still need some mechanism to cache your GitHub credentials in Git to enjoy the best experience with Sapling. For example, a graphical interface like [Interactive Smartlog](/docs/addons/isl.md) would be unpleasant to use if it prompted your for a password every time it needed to talk to GitHub. To avoid this, [GitHub recommends two solutions for caching your GitHub credentials](https://docs.github.com/en/get-started/getting-started-with-git/caching-your-github-credentials-in-git), the GitHub CLI being the primary choice.
 
 While GitHub [gives you the option](https://docs.github.com/en/get-started/getting-started-with-git/about-remote-repositories) of cloning a repo with either HTTPS or SSH URLs, HTTPS is generally considered easier to use because HTTPS default port 443 is far less likely to be blocked by a firewall than SSH default port 22.
 
@@ -31,15 +31,15 @@ When it comes to working with pull requests from Sapling, you have two options:
 
 ### `sl pr` (aka "Sapling stack")
 
-See the dedicated [Sapling Stack](./sapling-stack.md) page for more information.
+See the dedicated [Sapling Stack](/docs/git/sapling-stack.md) page for more information.
 
 **Pros:**
 
 - Works with any GitHub repo.
 
 **Cons:**
 
-- Creates "overlapping" pull requests that may be confusing to reviewers using the GitHub pull request UI. Reviewers are strongly encouraged to use [ReviewStack](../addons/reviewstack.md) for code review instead of GitHub.
+- Creates "overlapping" pull requests that may be confusing to reviewers using the GitHub pull request UI. Reviewers are strongly encouraged to use [ReviewStack](/docs/addons/reviewstack.md) for code review instead of GitHub.
 
 :::tip
 

website/docs/git/intro.md

@@ -10,12 +10,12 @@ Sapling supports Git in 2 modes: `.git` mode, and `.sl` mode.
 
 If you'd like to also run `git` commands, use `git clone` or `git init` to create the repo, then run `sl` commands in it. If you'd like to use `sl` exclusively, benefit more from Sapling's scalability features, use `sl clone` or `sl init` instead.
 
-Refer to [Git support modes](git_support_modes) for details.
+Refer to [Git support modes](/docs/git/git_support_modes.md) for details.
 
 ## Code review system integration
 
 ### GitHub
 
 Sapling has builtin support for GitHub. It enables features like showing whether a GitHub Pull Request is accepted or not.
 
-Refer to [Using Sapling with GitHub](github) for details.
+Refer to [Using Sapling with GitHub](/docs/git/github.md) for details.

website/docs/git/sapling-stack.md

@@ -2,19 +2,19 @@ import {Command} from '@site/elements'
 
 # Sapling stack
 
-Sapling comes with a [`pr` subcommand](../commands/pr.md) to help you work with GitHub pull requests.
+Sapling comes with a [`pr` subcommand](/docs/commands/pr.md) to help you work with GitHub pull requests.
 
 Once you have a stack of commits, you can use <Command name="pr" linkText="sl pr submit --stack" /> (or `sl pr s -s`) to create a pull request for each commit in the stack, or to update existing pull requests linked to the commits.
 
 :::caution
 
-Make sure you have followed the instructions to [authenticate with GitHub using the GitHub CLI `gh`](../introduction/getting-started#authenticating-with-github) before using `sl pr`.
+Make sure you have followed the instructions to [authenticate with GitHub using the GitHub CLI `gh`](/docs/introduction/getting-started.md#authenticating-with-github) before using `sl pr`.
 
 :::
 
 :::caution
 
-`sl pr submit` creates _overlapping_ commits where each pull request contains the commit that is intended to be reviewed as part of the pull request as well as all commits below it in the stack. This will not "look right" on GitHub, so collaborators who use this command are encouraged to use [ReviewStack](../addons/reviewstack.md) to review these pull requests, as ReviewStack will present only the commit that is intended to be reviewed for each pull request.
+`sl pr submit` creates _overlapping_ commits where each pull request contains the commit that is intended to be reviewed as part of the pull request as well as all commits below it in the stack. This will not "look right" on GitHub, so collaborators who use this command are encouraged to use [ReviewStack](/docs/addons/reviewstack.md) to review these pull requests, as ReviewStack will present only the commit that is intended to be reviewed for each pull request.
 
 :::
 

website/docs/git/submodule.md

@@ -2,7 +2,7 @@
 
 :::note
 
-This page is about using the [`.sl` mode](git_support_modes#sl-mode). Submodule support for the [`.git` mode](git_support_modes#git-mode) is WIP.
+This page is about using the [`.sl` mode](/docs/git/git_support_modes.md#sl-mode). Submodule support for the [`.git` mode](/docs/git/git_support_modes.md#git-mode) is WIP.
 
 :::
 

website/docs/introduction/differences-hg.md

@@ -5,7 +5,7 @@ sidebar_position: 50
 
 While Sapling began 10 years ago as a variant of Mercurial, it has evolved into its own source control system and has many incompatible differences with Mercurial.
 
-The list of differences below is not comprehensive, nor is it meant to be a competitive comparison of Mercurial and Sapling. It just highlights some interesting differences for curious people who are already familiar with Mercurial. Many of the differences from Git also apply to Mercurial and [that list](./differences-git.md) should be referred to as well. Sapling has substantial scaling, implementation, and format differences as well that are not covered here.
+The list of differences below is not comprehensive, nor is it meant to be a competitive comparison of Mercurial and Sapling. It just highlights some interesting differences for curious people who are already familiar with Mercurial. Many of the differences from Git also apply to Mercurial and [that list](/docs/introduction/differences-git.md) should be referred to as well. Sapling has substantial scaling, implementation, and format differences as well that are not covered here.
 
 #### Sapling has different default behavior and options for many commands.
 Sapling removes or changes the behavior of a number of Mercurial commands in order to make the behavior more consistent with modern expectations. For instance, in Sapling ‘sl log’ by default shows the history from your current commit. In Mercurial `hg log` shows the history of the entire repository at once.