Remove mentions of old sg/sg repo V2

docs/admin/audit_log.mdx

@@ -53,7 +53,7 @@ Here's a word-by-word breakout to demonstrate how the captured entry aligns with
 
 - **Security Events** - [A list of events](./security_event_logs) such as logins, site configuration updates, code host configuration updates (_These logs can be sent to the database for easier collection as well as to the standard output_).
 - **Gitserver Access** - Requests to the [`gitserver`](./deploy/scale.mdx#gitserver) component that is responsible for brokering transactions between the git repos on disk and all other Sourcegraph components.
-- **GraphQL Requests** - Requests To The Sourcegraph [`frontend`](./deploy/scale.mdx#frontend) component that is usually named `sourcegraph-frontend-{DYNAMICALLY CREATED ALPHANUMERIC}` 
+- **GraphQL Requests** - Requests To The Sourcegraph [`frontend`](./deploy/scale.mdx#frontend) component that is usually named `sourcegraph-frontend-{DYNAMICALLY CREATED ALPHANUMERIC}`
 
 This list is expected to grow in the future.
 
@@ -89,7 +89,7 @@ Audit logs are structured logs. As long as one can ingest logs, we assume one ca
 
 ### On Premises
 
-All logs mentioned are delivered to the standard output (stdout) for each individual [component](./deploy/scale.mdx#core-components). 
+All logs mentioned are delivered to the standard output (stdout) for each individual [component](./deploy/scale.mdx#core-components).
 
 
 There are two easy approaches to filtering the audit logs:
@@ -103,7 +103,7 @@ For Sourcegraph Cloud customers, please refer to Cloud [documentations](/cloud/#
 
 ## Developing
 
-The single entry point to the audit logging API is made via the [`audit.Log`](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/audit/audit.go?L19) function. This internal function can be used from any place in the app, and nothing else needs to be done for the logged entry to appear in the audit log.
+The single entry point to the audit logging API is made via the `audit.Log` function. This internal function can be used from any place in the app, and nothing else needs to be done for the logged entry to appear in the audit log.
 
 Example call:
 ```

docs/admin/config/advanced_config_file.mdx

@@ -90,8 +90,6 @@ Where `extsvc.json` contains a JSON object that specifies _all_ of your code hos
 }
 ```
 
-You can find a full list of [valid top-level keys here](https://sourcegraph.com/github.com/sourcegraph/sourcegraph-public-snapshot@b7ebb9024e3a95109fdedfb8057795b9a7c638bc/-/blob/cmd/frontend/graphqlbackend/schema.graphql#L1104-1110).
-
 If you want to _allow_ edits to be made through the web UI (which will be overwritten with what is in the file on a subsequent restart), you may additionally set `EXTSVC_CONFIG_ALLOW_EDITS=true`. **Note** that if you do enable this, it is your responsibility to ensure the configuration on your instance and in the file remain in sync.
 
 ## Global settings

docs/admin/enterprise_getting_started_guide/index.mdx

@@ -18,7 +18,7 @@ If you're deploying a new Enterprise instance, this page covers our most frequen
 - [GitHub integration](/integration/github)
 - [All code host integrations (not GitLab or GitHub)](/integration/#integrations)
 - [Full guide to site config options](/admin/config/site_config#auth-sessionExpiry)
-- [Changelog](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/CHANGELOG) to track releases and updates
+- [Changelog](https://sourcegraph.com/changelog) to track releases and updates
 
 ### Docker-compose
 - [Basic installation guide](/admin/deploy/docker-compose/)

docs/admin/executors/deploy_executors_binary.mdx

@@ -155,7 +155,7 @@ If you use the systemd service, simply run `systemctl start executor`, otherwise
 ## Upgrading executors
 
 Upgrading executors is relatively uninvolved. Simply follow the instructions below.
-Also, check the [changelog](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@main/-/blob/CHANGELOG) for any Executors related breaking changes or new features that you might want to configure.
+Also, check the [changelog](https://sourcegraph.com/changelog) for any Executors related breaking changes or new features that you might want to configure.
 
 ### **Step 1:** First, grab the executor binary for the new target Sourcegraph version.
 

docs/admin/executors/deploy_executors_binary_offline.mdx

@@ -168,7 +168,7 @@ To install the Firecracker sandbox image, import the image using `docker`.
 $ docker pull <docker repository image for sourcegraph/ignite:v0.10.5>
 ```
 
-> Note: Check the [version](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@main/-/blob/cmd/executor/internal/config/consts.go?L15) against the version of executors being installed.
+> Note: Check the version against the version of executors being installed.
 
 If you are using a custom image instead of the Sourcegraph image, you will need to set the environment variable
 `EXECUTOR_FIRECRACKER_SANDBOX_IMAGE` to match the image name.
@@ -181,7 +181,7 @@ To install the Firecracker Kernel image, import the image (`sourcegraph/ignite-k
 $ ignite kernel import --runtime docker <docker repository image for sourcegraph/ignite-kernel:5.10.135-amd64>
 ```
 
-> Note: Check the [version](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@main/-/blob/cmd/executor/internal/config/consts.go?L18) against the version of executors being installed.
+> Note: Check the version against the version of executors being installed.
 
 If you are using a custom image instead of the Sourcegraph image, you will need to set the environment variable
 `EXECUTOR_FIRECRACKER_KERNEL_IMAGE` to match the image name.

docs/admin/executors/deploy_executors_kubernetes.mdx

@@ -134,6 +134,4 @@ The Executor Docker image is available on Docker Hub at [`sourcegraph/executor-k
 
 ### Example Configuration YAML
 
-See
-the [local development YAMLs](https://sourcegraph.com/github.com/sourcegraph/sourcegraph-public-snapshot@main/-/blob/cmd/executor/kubernetes)
-for an example of how to configure the Executor in Kubernetes.
+See the local development YAMLs for an example of how to configure the Executor in Kubernetes.

docs/admin/executors/firecracker.mdx

@@ -41,4 +41,4 @@ Executor can be fined tuned with the following environment variables,
 
 ## Known caveats
 
-We [configure iptables](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/cmd/executor/internal/run/install.go?L229-255) to prevent Firecracker-isolated processes from talking on [Private IPv4 Addresses](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses) (providing network-level isolation). They can talk to DNS and Sourcegraph only, which prevents users from talking to a 10.x.x.x, 172.x.x.x, or 192.168.x.x range IP.
+We configure iptables to prevent Firecracker-isolated processes from talking on [Private IPv4 Addresses](https://en.wikipedia.org/wiki/Private_network#Private_IPv4_addresses) (providing network-level isolation). They can talk to DNS and Sourcegraph only, which prevents users from talking to a 10.x.x.x, 172.x.x.x, or 192.168.x.x range IP.

docs/admin/how-to/dirty_database_pre_3_37.mdx

@@ -51,7 +51,7 @@ _Note: for codeintel the schema version table is called `codeintel_schema_migrat
 
 ### 2. Run the sql queries to finish incomplete migrations
 
-Sourcegraph's migration files take for form of `sql` files following the snake case naming schema `<version>_<description>.<up or down>.sql` and can be found [here](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/tree/migrations) in subdirectories for the specific database. _Note frontend is the pgsql database_.
+Sourcegraph's migration files take for form of `sql` files following the snake case naming schema `<version>_<description>.<up or down>.sql` in subdirectories for the specific database. _Note frontend is the pgsql database_.
 
 1. **Find the up migration starting with the migration's version number identified in [step 1](#1-identify-incomplete-migration):** making sure to go to \<YOUR-SOURCEGRAPH-VERSION\>
 

docs/admin/how-to/monorepo-issues.mdx

@@ -18,7 +18,7 @@ The following bullets provide a general guidline to which service may require mo
 
 If you are regularly seeing the `Processing symbols is taking longer than expected. Try again in a while` warning in your sidebar, its likely that your symbols and/or gitserver services are underprovisioned and need more CPU/mem resources.
 
-The [symbols sidebar](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/client/web/src/repo/RepoRevisionSidebarSymbols.tsx?L42) is dependent on the symbols and gitserver services. Upon opening the symbols sidebar, a search query is made to the GraphQL API to retrieve the symbols associated with the current git commit. You can read more about the [symbol search behavior and performance](/code-search/types/symbol#symbol-search-behavior-and-performance).
+The symbols sidebar is dependent on the symbols and gitserver services. Upon opening the symbols sidebar, a search query is made to the GraphQL API to retrieve the symbols associated with the current git commit. You can read more about the [symbol search behavior and performance](/code-search/types/symbol#symbol-search-behavior-and-performance).
 
 To address this concern, allocate more resources to the symbols service (to provide more processing power for indexing operations) and allocate more resources to the gitserver (to provide for the extra load associated with responding to fetch requests from symbols, and speed up sending the large repo).
 

docs/admin/how-to/redis_configmap.mdx

@@ -44,7 +44,7 @@ Reference Materials
 
 
 
-1. Locate the original redis-cache configuration file: [https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/docker-images/redis-cache/redis.conf](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/docker-images/redis-cache/redis.conf) Use this as the “Default redis.conf file” content in the ConfigMap. Adding `requirepass` sets the password for Redis authentication.
+1. Locate the original redis-cache configuration file. Use this as the “Default `redis.conf` file” content in the ConfigMap. Adding `requirepass` sets the password for Redis authentication.
 2. Create the redis-cache-conf ConfigMap:
 
 ```
@@ -110,9 +110,9 @@ spec:
 ```
 
 
-4. Locate the original redis-store configuration file. [https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/docker-images/redis-store/redis.conf](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/docker-images/redis-store/redis.conf) Use this as the “Default redis.conf file” content in the ConfigMap.
+1. Locate the original redis-store configuration file. Use this as the “Default `redis.conf` file” content in the ConfigMap.
 
-5. Create the redis-store-conf ConfigMap:
+2. Create the redis-store-conf ConfigMap:
 
 ```
  apiVersion: v1

docs/admin/pings.mdx

@@ -252,15 +252,15 @@ The Cody app connects to Sourcegraph.com to send a limited selection of the ping
 
 It may happen that Sourcegraph will stop sending critical telemetry to Sourcegraph.com, if this happens it may indicate a problem with Sourcegraphs frontend database, or a site settings misconfiguration. Below are some debugging steps.
 
-Sourcegraph telemetry pings are handled by a goroutine running on Sourcegraphs frontend service called [`updatecheck`](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/cmd/frontend/internal/app/updatecheck/client.go?subtree=true), `updatecheck` is [started](https://sourcegraph.com/search?q=context:global+repo:%5Egithub%5C.com/sourcegraph/sourcegraph%24+file:%5Ecmd/frontend/internal/cli/serve_cmd%5C.go+updatecheck.Start%28db%29&patternType=literal) on container startup and periodically requests a variety of queries be run in the `pgsql` database.
+Sourcegraph telemetry pings are handled by a goroutine running on Sourcegraphs frontend service called `updatecheck`, `updatecheck` is started on container startup and periodically requests a variety of queries be run in the `pgsql` database.
 
 
 ### Misconfigured update.channel
 The most common scenario in which Sourcegraph stops sending pings is a change to the `update.channel` setting in an instance's [site config](https://sourcegraph.com/docs/admin/config/site_config)
 ```
 "update.channel": "release",
 ```
-*This setting [must be set to "release"](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/updatecheck/client.go?L803-806) in order for the telemetry goroutine to run.*
+*This setting must be set to "release" in order for the telemetry goroutine to run.*
 
 
 ### Check if the goroutine is running

docs/admin/repo/perforce.mdx

@@ -52,9 +52,7 @@ To enable Perforce code host connections, a site admin must:
 
     > NOTE: While the `fusionClient` configuration is optional, without it the code host connection uses `git p4`, which has performance issues so we strongly recommend `p4-fusion`.
 
-    Details of all `p4-fusion` configuration fields can be seen [here](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@2a716bd70c294acf1b3679b790834c4dea9ea956/-/blob/schema/perforce.schema.json?L84-147).
-
-1. Click **Add repositories**.
+2. Click **Add repositories**.
 
 Sourcegraph will now talk to the Perforce host and sync the configured `depots` to the Sourcegraph instance.
 
@@ -73,11 +71,11 @@ Perforce labels are converted to Git tags, but only under the following conditio
 
 Perforce label names are also more flexible than git tag names, so incompatible characters are replaced with underscores. (i.e. `v1:2:3` will become `v1_2_3`)
 
-This behaviour can be disabled by setting `noConvertLabels` to `true` in the [fusion client configuration](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@44e848d4ba5a3d47bc6e8651638cfe2279d02102/-/blob/schema/perforce.schema.json?L66-131).
+This behaviour can be disabled by setting `noConvertLabels` to `true` in the fusion client configuration.
 
 ## Repository permissions (Beta)
 
-To enforce file-level permissions for Perforce depots using the [Perforce protects file](https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_protect.html), include [the `authorization` field](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@2a716bd70c294acf1b3679b790834c4dea9ea956/-/blob/schema/perforce.schema.json?L67-78) in the configuration of the Perforce code host connection you created [above](#add-a-perforce-code-host):
+To enforce file-level permissions for Perforce depots using the [Perforce protects file](https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_protect.html), include the `authorization` field in the configuration of the Perforce code host connection you created [above](#add-a-perforce-code-host):
 
 ```json
 {
@@ -130,7 +128,7 @@ File-level permissions eliminate the need for [syncing subdirectories to match p
 
 To enable file-level permissions:
 
-1. Add the following entry to your [site configuration file](https://sourcegraph.com/github.com/sourcegraph/sourcegraph@2a716bd/-/blob/schema/site.schema.json?L227-249):
+1. Add the following entry to your site configuration file:
 
     ```json
     {
@@ -140,7 +138,7 @@ To enable file-level permissions:
     }
     ```
 
-1. Enable the feature in the code host configuration by adding `subRepoPermissions` to the `authorization` object:
+2. Enable the feature in the code host configuration by adding `subRepoPermissions` to the `authorization` object:
 
     ```json
     {
@@ -150,7 +148,7 @@ To enable file-level permissions:
     }
     ```
 
-1. Save the configuration.
+3. Save the configuration.
 
 Permissions will be synced in the background based on your [Perforce protects file](https://www.perforce.com/manuals/cmdref/Content/CmdRef/p4_protect.html).
 

docs/admin/security_event_logs.mdx

@@ -1,10 +1,12 @@
 # Security Event Logs
+
 This guide goes into the details of Security Event Logging in Sourcegraph
 > Note: You can find more information about our audit logs setup [here](./audit_log)
 >
 > [Here](https://docs-legacy.sourcegraph.com/dev/how-to/add_logging) is a guide on how to add logging to Sourcegraph backend
 
 ## What are Security Event Logs
+
 - The purpose of Security Event Logs is to allow security specialists to be able to trace the steps of a user or an admin across the application.
 - Getting a full picture of how a user moves through the application, in a single location, is crucial for many reasons.
 - When a user takes an action on sensitive information within the application, this should be logged to make sure it can be retraced to the user and time.
@@ -15,7 +17,8 @@ This guide goes into the details of Security Event Logging in Sourcegraph
 
 
 ## How to log a security event
-- All the logging for security event is done through our [security_event_log.go](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/database/security_event_logs.go) functions
+
+- All the logging for security event is done through our `security_event_log` functions
 - Previously, events were created within the function where the action was taking place and then pushed to the logging location like this:
   ```go
   event := &SecurityEvent{
@@ -30,10 +33,10 @@ This guide goes into the details of Security Event Logging in Sourcegraph
 
 	db.SecurityEventLogs().LogEvent(ctx, event)
 
-- With a recent change to streamline the process, to log an event, the [LogSecurityEvent](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/database/security_event_logs.go?L253:34&popover=pinned) function can be invoked which takes care of marshaling the arguments and creating the SecurityEvent.
+- With a recent change to streamline the process, to log an event, the `LogSecurityEvent` function can be invoked which takes care of marshaling the arguments and creating the SecurityEvent.
 - This function takes following information to create a log event
   - Context contains information on the acting user
-  - SecurityEventName which is predefined [here](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/database/security_event_logs.go?L22-101)
+  - `SecurityEventName` is predefined
   - URL if available
   - userID of the user that the action is applied towards
   - anonymousUserID for unauthenticated users
@@ -96,8 +99,6 @@ This guide goes into the details of Security Event Logging in Sourcegraph
 - UserID can be used to filter out actions taken on a particular user's information
 
 ## FAQ
-### What events are currently being logged as security events?
-- [These](https://sourcegraph.com/github.com/sourcegraph/sourcegraph/-/blob/internal/database/security_event_logs.go?L22-101) are the events that are currently being logged.
 
 ### What if I don't want these events to be logged?
 

docs/cloud/index.mdx

@@ -154,7 +154,7 @@ To learn more about how the Sourcegraph team operates managed SMTP internally, r
 ### Audit Logs
 
 Our Cloud instances provide [audit logs](/admin/audit_log#cloud) to help you monitor and investigate actions taken by users and the system. These logs are available to download by request and are also sent to a [centralized logging service](https://about.sourcegraph.com/security#logging) for 30 day retention. Should you wish to
-extend this period, please be aware that additional charges will apply. 
+extend this period, please be aware that additional charges will apply.
 To request an extension, please contact your assigned Customer Engineer (CE) or send an email to Sourcegraph Support at support@sourcegraph.com.
 
 #### Download audit logs
@@ -283,7 +283,6 @@ The below are for example purposes only:
 
 In the case of things like Code Search, latency is directly correlated with user input / shape of the query, ex. on our public [sourcegraph.com](https://sourcegraph.com/search) instance:
 
-- searching for “squirrel” in the [sourcegraph/sourcegraph](https://sourcegraph.com/github.com/sourcegraph/sourcegraph) repo takes 30ms and returns 163 results
 - searching for “squirrel” in all OSS repos, but only requesting 1000 matches takes 540ms
 - searching for all matches of “squirrel” in all OSS repos returns 1.7million results in 30000ms
 - In the case of other features, latency of Sourcegraph directly depends on latency / uptime / rate-limits of customer managed systems, ex. for: