publish

packages/doltgres/content/reference/sql/version-control/dolt-system-tables.md

@@ -52,7 +52,6 @@ title: Dolt System Tables
 
   - [dolt_rebase](#dolt_rebase)
 
-
 # Database Metadata System Tables
 
 ## `dolt_branches`
@@ -191,7 +190,6 @@ CREATE PROCEDURE simple_proc2() SELECT name FROM category;
 
 {% embed url="https://www.dolthub.com/repositories/dolthub/first-hour-db/embed/main?q=SELECT+*+FROM+dolt_procedures%3B" %}
 
-
 ## `dolt_query_catalog`
 
 The `dolt_query_catalog` system table stores named queries for your database.
@@ -413,7 +411,7 @@ Get all the tags.
 
 For every user table that has a primary key, there is a queryable system view named `dolt_blame_$tablename`
 which can be queried to see the user and commit responsible for the current value of each row.
-This is equivalent to the [`dolt blame` CLI command](../../cli/cli.md#dolt-blame).
+This is equivalent to the [`dolt blame` CLI command](https://docs.dolthub.com/cli-reference/cli#dolt-blame).
 Tables without primary keys will not have an associated `dolt_blame_$tablename`.
 
 ### Schema
@@ -456,8 +454,6 @@ To find who set the current values, we can query the `dolt_blame_city` table:
 
 {% embed url="https://www.dolthub.com/repositories/dolthub/first-hour-db/embed/main?q=select+*+from+dolt_blame_city%3B" %}
 
-
-
 ## `dolt_commit_ancestors`
 
 The `dolt_commit_ancestors` table records the ancestors for every commit in the database. Each commit has one or two
@@ -479,7 +475,6 @@ merged will have `parent_index` 1.
 +--------------+------+------+-----+---------+-------+
 ```
 
-
 ## `dolt_commits`
 
 The `dolt_commits` system table shows _ALL_ commits in a Dolt database.
@@ -512,7 +507,6 @@ we can query for the five commits before April 20th, 2022, across all commits in
 
 {% embed url="https://www.dolthub.com/repositories/dolthub/first-hour-db/embed/main?q=SELECT+*%0AFROM+dolt_commits%0Awhere+date+%3C+%222022-04-20%22%0A" %}
 
-
 ## `dolt_history_$TABLENAME`
 
 For every user table named `$TABLENAME`, there is a read-only system table named `dolt_history_$TABLENAME`
@@ -599,7 +593,6 @@ The following query shows the commits reachable from the current checked out hea
 
 {% embed url="https://www.dolthub.com/repositories/dolthub/first-hour-db/embed/main?q=SELECT+*%0AFROM+dolt_log%0AWHERE+committer+%3D+%22jennifersp%22+and+date+%3E+%222022-04-01%22%0AORDER+BY+date%3B" %}
 
-
 # Database Diffs
 
 ## `dolt_commit_diff_$TABLENAME`
@@ -906,7 +899,6 @@ num_inmates_rated_for have changed the most between 2 versions.
 
 {% embed url="https://www.dolthub.com/repositories/dolthub/us-jails/embed/main?q=SELECT+to_county%2C+from_county%2Cto_num_inmates_rated_for%2Cfrom_num_inmates_rated_for%2C++abs%28to_num_inmates_rated_for+-+from_num_inmates_rated_for%29+AS+delta%0AFROM+dolt_diff_jails%0AWHERE+from_commit+%3D+HASHOF%28%22HEAD~3%22%29+AND+diff_type+%3D+%22modified%22%0AORDER+BY+delta+DESC%0ALIMIT+10%3B%0A" %}
 
-
 # Working Set Metadata System Tables
 
 ## `dolt_conflicts`
@@ -1229,7 +1221,7 @@ WHERE staged=true;
 
 ## `dolt_rebase`
 
-`dolt_rebase` is only present while an interactive rebase is in progress, and only on the branch where the rebase is being executed. For example, when rebasing the `feature1` branch, the rebase will be executed on the `dolt_rebase_feature1` branch, and the `dolt_rebase` system table will exist on that branch while the rebase is in-progress. The `dolt_rebase` system table starts off with the default rebase plan, which is to `pick` all of the commits identified for the rebase. Users can adjust the rebase plan by updating the `dolt_rebase` table to change the rebase action, reword a commit message, or even add new rows with additional commits to be applied as part of the rebase. For more details about rebasing, see [the `dolt_rebase()` stored procedure](dolt-sql-procedures.md#dolt_rebase).  
+`dolt_rebase` is only present while an interactive rebase is in progress, and only on the branch where the rebase is being executed. For example, when rebasing the `feature1` branch, the rebase will be executed on the `dolt_rebase_feature1` branch, and the `dolt_rebase` system table will exist on that branch while the rebase is in-progress. The `dolt_rebase` system table starts off with the default rebase plan, which is to `pick` all of the commits identified for the rebase. Users can adjust the rebase plan by updating the `dolt_rebase` table to change the rebase action, reword a commit message, or even add new rows with additional commits to be applied as part of the rebase. For more details about rebasing, see [the `dolt_rebase()` stored procedure](dolt-sql-procedures.md#dolt_rebase).
 
 ### Schema
 
@@ -1245,30 +1237,35 @@ WHERE staged=true;
 ```
 
 The `action` field can take one of the following rebase actions:
+
 - `pick` - apply a commit as is and keep its commit message.
 - `drop` - do not apply a commit. The row in the `dolt_rebase` table can also be deleted to drop a commit from the rebase plan.
-- `reword` - apply a commit, and use the updated commit message from the `commit_message` field in the `dolt_rebase` table for its commit message. Note that if you edit the `commit_message` but do not use the `reword` action, the original commit message will still be used. 
+- `reword` - apply a commit, and use the updated commit message from the `commit_message` field in the `dolt_rebase` table for its commit message. Note that if you edit the `commit_message` but do not use the `reword` action, the original commit message will still be used.
 - `squash` - apply a commit, but include its changes in the previous commit instead of creating a new commit. The commit message of the previous commit will be altered to include the previous commit message as well as the commit message from the squashed commit. Note that the rebase plan MUST include a `pick` or `reword` action in the plan before a `squash` action.
-- `fixup` - apply a commit, but include its changes in the previous commit instead of creating a new commit. The commit message of the previous commit will NOT be changed, and the commit message from the fixup commit will be discarded.  Note that the rebase plan MUST include a `pick` or `reword` action in the plan before a `fixup` action.
+- `fixup` - apply a commit, but include its changes in the previous commit instead of creating a new commit. The commit message of the previous commit will NOT be changed, and the commit message from the fixup commit will be discarded. Note that the rebase plan MUST include a `pick` or `reword` action in the plan before a `fixup` action.
 
 ### Example Queries
 
 To squash all commits into a single commit and include the commit messages from all commits, the following query can be used:
+
 ```sql
 update dolt_rebase set action = 'squash' where rebase_order > 1;
 ```
 
 To reword a commit with commit hash '123aef456f', be sure to set the action to `reword` and to update the `commit_message` field:
+
 ```sql
 update dolt_rebase set action = 'reword', commit_message = 'here is my new message' where commit_hash = '123aef456f';
 ```
 
 To drop the second commit in the rebase plan, you can use the `drop` action:
+
 ```sql
 update dolt_rebase set action = 'drop' where rebase_order = 2;
 ```
 
 Or you can simply delete that row from the `dolt_rebase` table:
+
 ```sql
 delete from dolt_rebase where rebase_order = 2;
 ```

packages/doltgres/content/reference/sql/version-control/remotes.md

@@ -20,8 +20,7 @@ named `origin` is automatically configured for you.
 <h1 id="pushing-to-remote">Pushing to a Remote</h1>
 
 Let's go through an example of how you can push data from a local Doltgres database to a remote. In
-this example, we'll use the running Doltgres server we created in the [Getting
-Started](../../../concepts/rdbms/database.md) section to push a branch a file-based remote.
+this example, we'll use the running Doltgres server we created in the [Getting Started](../../../concepts/rdbms/README.md) section to push a branch a file-based remote.
 
 First, we need to add a new remote:
 

packages/doltlab/content/guides/administrator/administrator.md

@@ -10,7 +10,7 @@ This guide will cover how to perform common DoltLab administrator configuration
 4. [Send service logs to the DoltLab team](#send-service-logs)
 5. [Authenticate a Dolt client to use a DoltLab account](#auth-dolt-client)
 6. [Monitor DoltLab with cAdvisor and Prometheus](#prometheus)
-7.  [Connect DoltLab to an SMTP server](#connect-smtp-server)
+7. [Connect DoltLab to an SMTP server](#connect-smtp-server)
 8. [Connect DoltLab to an SMTP server with implicit TLS](#smtp-implicit-tls)
 9. [Troubleshoot SMTP server connection problems](#troubleshoot-smtp-connection)
 10. [Set up a SMTP server using any Gmail address](#set-up-a-smtp-server-using-any-gmail-address)
@@ -26,7 +26,7 @@ This guide will cover how to perform common DoltLab administrator configuration
 
 <h1 id="issues-release-notes">File issues and view release notes</h1>
 
-DoltLab's source code is currently closed, but you can file DoltLab issues the [issues repository](https://github.com/dolthub/doltlab-issues). Release notes are available [here](../introduction/installation/release-notes.md).
+DoltLab's source code is currently closed, but you can file DoltLab issues the [issues repository](https://github.com/dolthub/doltlab-issues). Release notes are available [here](../../release-notes.md).
 
 <h1 id="backup-restore-volumes">Backup and restore volumes</h1>
 
@@ -98,7 +98,7 @@ docker volume rm doltlab_doltlabdb-dolt-data
 docker volume rm doltlab_doltlabdb-dolt-backups
 ```
 
-Next, [start DoltLab's services](../introduction/installation/start-doltlab.md) using the `start.sh` script. After the script completes, stop DoltLab once more with `./stop.sh`. Doing this will recreate the required containers so that their volumes can be updated with the commands below.
+Next, [start DoltLab's services](../installation/start-doltlab.md) using the `start.sh` script. After the script completes, stop DoltLab once more with `./stop.sh`. Doing this will recreate the required containers so that their volumes can be updated with the commands below.
 
 Once the services are stopped, `cd` into the directory containing the `remote-data.tar` backup file and run:
 
@@ -354,7 +354,7 @@ Additionally, TLS verification can be skipped by adding the additional argument
 
 DoltLab requires a connection to an existing SMTP server in order for users to create accounts, verify email addresses, reset forgotten passwords, and collaborate on databases.
 
-DoltLab creates a [default user](../../introduction/installation/start-doltlab.md), `admin`, when if first starts up, which allows administrators to sign-in to their DoltLab instance, even if they are experiencing SMTP server connection issues.
+DoltLab creates a [default user](../installation/start-doltlab.md), `admin`, when if first starts up, which allows administrators to sign-in to their DoltLab instance, even if they are experiencing SMTP server connection issues.
 
 To help troubleshoot and resolve SMTP server connection issues, we've published the following [go tool](https://github.com/dolthub/doltlab-issues/blob/main/go/cmd/smtp_connection_helper/main.go) to help diagnose the SMTP connection issues on the host running DoltLab.
 
@@ -610,7 +610,7 @@ You can now restart DoltLab with the `./start.sh` script, and it will be served
 
 <h1 id="doltlab-performance">Improve DoltLab performance</h1>
 
-It is possible to limit the number of concurrent Jobs running on a DoltLab host, which might be starving the host for resources and affecting DoltLab's performance. 
+It is possible to limit the number of concurrent Jobs running on a DoltLab host, which might be starving the host for resources and affecting DoltLab's performance.
 
 When users upload files on a DoltLab instance, or merge a pull request, DoltLab creates a Job corresponding to this work. These Jobs spawn new Docker containers that performs the required work.
 

packages/doltlab/content/guides/administrator/enterprise.md

@@ -4,7 +4,7 @@ title: "DoltLab Enterprise Guide"
 
 This guide will cover how to run DoltLab in Enterprise mode and use exclusive features not covered in the [Administrator's Guide](../administrator/administrator.md).
 
-To start DoltLab in Enterprise mode, when [running the installer](../introduction/installation/start-doltlab.md) supply the following additional arguments:
+To start DoltLab in Enterprise mode, when [running the installer](../installation/start-doltlab.md) supply the following additional arguments:
 
 ```bash
 ./installer \
@@ -34,7 +34,7 @@ You can use a custom logo on DoltLab by running the `installer` with the argumen
 
 DoltLab Enterprise allows administrators to customize the automated emails their DoltLab instance sends to its users.
 
-Custom emails can be configured with the `installer` by supplying the argument `--custom-email-templates=true`. The installer will generate the email template files at `./doltlabapi/templates/email` which match the files described below. You can customize these files and they will be used by DoltLab. Each file is named according to use-case. The names and paths of these files should NOT be changed. 
+Custom emails can be configured with the `installer` by supplying the argument `--custom-email-templates=true`. The installer will generate the email template files at `./doltlabapi/templates/email` which match the files described below. You can customize these files and they will be used by DoltLab. Each file is named according to use-case. The names and paths of these files should NOT be changed.
 
 - `collabInvite.txt` sent to invite user to be a database collaborator.
 - `invite.txt` sent to invite a user to join an organization.

packages/doltlab/content/guides/administrator/pre-installer-administrator-guide.md

@@ -94,7 +94,7 @@ docker volume rm doltlab_doltlabdb-dolt-data
 docker volume rm doltlab_doltlabdb-dolt-backups
 ```
 
-Next, [start DoltLab's services](../introduction/installation/start-doltlab-pre-installer.md) using the `start-doltlab.sh` script. After the script completes, stop DoltLab once more with `docker-compose stop`. Doing this will recreate the required containers so that their volumes can be updated with the commands below.
+Next, [start DoltLab's services](../../older/installation/start-doltlab-pre-installer.md) using the `start-doltlab.sh` script. After the script completes, stop DoltLab once more with `docker-compose stop`. Doing this will recreate the required containers so that their volumes can be updated with the commands below.
 
 Once the services are stopped, `cd` into the directory containing the `remote-data.tar` backup file and run:
 
@@ -187,7 +187,7 @@ SET session_replication_role = replica;
 ...
 ```
 
-[Start DoltLab's services](./installation.md#start-doltlab) again using the `start-doltlab.sh` script. After the script completes, `cd` into the directory containing the `postgres-dump.sql` file and run:
+[Start DoltLab's services](../installation/start-doltlab.md) again using the `start-doltlab.sh` script. After the script completes, `cd` into the directory containing the `postgres-dump.sql` file and run:
 
 > For DoltLab `v0.7.0` and later, use `--network doltlab` below.
 

packages/doltlab/content/guides/installation/linux.md

@@ -17,6 +17,7 @@ cd doltlab
 ```
 
 Or, to install a specific version of DoltLab, run:
+
 ```bash
 export DOLTLAB_VERSION=v2.1.1
 curl -LO https://doltlab-releases.s3.amazonaws.com/linux/amd64/doltlab-${DOLTLAB_VERSION}.zip
@@ -28,12 +29,12 @@ The contents of the resulting `doltlab` directory can vary depending on the vers
 
 Inside the `doltlab` directory you'll find the following binaries:
 
-* installer
-* smtp_connection_helper
+- installer
+- smtp_connection_helper
 
 The `installer` binary, is the primary interface for configuring a DoltLab instance. This tool will create all other assets DoltLab needs to run, based on the arguments you supply it.
 
-The `smtp_connection_helper` binary can be used to help you troubleshoot any issues connecting your DoltLab instance to your existing SMTP server. This tool uses similar code to DoltLab's email service and sends a test email if the connection to the SMTP server is properly configured. The source code for the tool is available [here](https://gist.github.com/coffeegoddd/66f5aeec98640ff8a22a1b6910826667) and basic instructions for using the tool are [here](./administrator.md#troubleshoot-smtp-connection).
+The `smtp_connection_helper` binary can be used to help you troubleshoot any issues connecting your DoltLab instance to your existing SMTP server. This tool uses similar code to DoltLab's email service and sends a test email if the connection to the SMTP server is properly configured. The source code for the tool is available [here](https://gist.github.com/coffeegoddd/66f5aeec98640ff8a22a1b6910826667) and basic instructions for using the tool are [here](../administrator/administrator.md#troubleshoot-smtp-connection).
 
 # Next Steps
 

packages/doltlab/content/guides/installation/start-doltlab.md

@@ -2,7 +2,7 @@
 title: Start DoltLab
 ---
 
-The following describes how to start the latest versions of DoltLab, >= `v2.1.2`, that contain the `installer` binary. For instructions on how to start an older version of DoltLab that do not have the `installer`, please see the [pre-installer guide](./start-doltlab-pre-installer.md).
+The following describes how to start the latest versions of DoltLab, >= `v2.1.2`, that contain the `installer` binary. For instructions on how to start an older version of DoltLab that do not have the `installer`, please see the [pre-installer guide](../../older/installation/start-doltlab-pre-installer.md).
 
 In the simplest configuration the `installer` will generate four local DoltLab assets: a `docker-compose.yaml` file, an `envoy.json` file, a `start.sh` script, and a `stop.sh` script.
 
@@ -37,12 +37,12 @@ If the argument `--default-user-email` is not provided to the `installer` before
 
 Additionally, the first time the `installer` is run, it will generate the all passwords it needs to initialize your DoltLab instance. These passwords are stored in `./.secrets`.
 
-* `./.secrets/default_user_pass.priv`, contains the password for the default user.
-* `./.secrets/dolt_admin_password.priv`, contains the `dolthubadmin` password for DoltLab's application database.
-* `./.secrets/dolt_dolthubapi_password.priv`, contains the `dolthubapi` password for DoltLab's application database.
-* `./.secrets/smtp_username.priv`, contains the SMTP username for an SMTP server. This will have a placeholder value if no SMTP server is configured.
-* `./.secrets/smtp_password.priv`, contains the SMTP password for an SMTP server. This will have a placeholder value if no SMTP server is configured.
-* `./.secrets/smtp_oauth_token.priv`, contains the SMTP oauth token for an SMTP server. This will have a placeholder value if no SMTP server is configured.
+- `./.secrets/default_user_pass.priv`, contains the password for the default user.
+- `./.secrets/dolt_admin_password.priv`, contains the `dolthubadmin` password for DoltLab's application database.
+- `./.secrets/dolt_dolthubapi_password.priv`, contains the `dolthubapi` password for DoltLab's application database.
+- `./.secrets/smtp_username.priv`, contains the SMTP username for an SMTP server. This will have a placeholder value if no SMTP server is configured.
+- `./.secrets/smtp_password.priv`, contains the SMTP password for an SMTP server. This will have a placeholder value if no SMTP server is configured.
+- `./.secrets/smtp_oauth_token.priv`, contains the SMTP oauth token for an SMTP server. This will have a placeholder value if no SMTP server is configured.
 
 DoltLab uses the values of `DOLT_PASSWORD` and `DOLTHUBAPI_PASSWORD` contained in the generated secrets to initialize DoltLab's application database using the following SQL statements: