Merge pull request #46217 from github/repo-sync

Repo sync

Author: docs-bot

content/code-security/concepts/secret-security/secret-scanning.md

@@ -69,9 +69,7 @@ Beyond the default detection of partner and provider secrets, you can expand and
 
 ### About validity checks
 
-Validity checks help you prioritize which secrets to remediate first by verifying whether a detected secret is still active. When you enable validity checks, {% data variables.product.prodname_secret_scanning %} may contact the secret's issuing service to determine if the credential has been revoked.
-
-Validity checks are separate from {% data variables.product.prodname_secret_scanning %}'s partner program. While partner secrets are automatically reported to service providers for revocation, validity checks verify the status of secrets you manage in your own alerts. For more information, see [AUTOTITLE](/code-security/concepts/secret-security/validity-checks).
+Validity checks help you prioritize which secrets to remediate first by verifying whether a detected secret is still active. When you enable validity checks, {% data variables.product.prodname_secret_scanning %} may contact the secret's issuing service to determine if the credential has been revoked. For more information, see [AUTOTITLE](/code-security/concepts/secret-security/validity-checks).
 
 {% endif %}
 

content/copilot/how-tos/copilot-cli/customize-copilot/use-byok-models.md

@@ -1,6 +1,6 @@
 ---
-title: Using your own LLM models in GitHub Copilot CLI
-shortTitle: Use your own model provider
+title: Adding LLM models to GitHub Copilot CLI
+shortTitle: Add LLM models
 intro: 'Use a model from an external provider of your choice in {% data variables.product.prodname_copilot_short %} by supplying your own API key.'
 allowTitleToDifferFromFilename: true
 versions:
@@ -14,7 +14,7 @@ docsTeamMetrics:
   - copilot-cli
 ---
 
-You can configure {% data variables.copilot.copilot_cli_short %} to use your own LLM provider, also called BYOK (Bring Your Own Key), instead of {% data variables.product.github %}-hosted models. This lets you connect to OpenAI-compatible endpoints, Azure OpenAI, or Anthropic, including locally running models such as Ollama.
+You can configure {% data variables.copilot.copilot_cli_short %} to include models from an LLM provider of your choice—using BYOK (Bring Your Own Key)—in addition to the {% data variables.product.github %}-hosted models. This lets you connect to OpenAI-compatible endpoints, Azure OpenAI, or Anthropic, including locally running models such as Ollama.
 
 > [!NOTE]
 > This article is for users who want to configure their own LLM provider API key on their local machine. To set up custom models for users in an enterprise, see [AUTOTITLE](/copilot/how-tos/administer-copilot/manage-for-enterprise/enable-custom-models).
@@ -143,5 +143,5 @@ You can run {% data variables.copilot.copilot_cli_short %} in offline mode to pr
    ```shell
    export COPILOT_OFFLINE=true
    ```
-   
+
 1. {% data reusables.copilot.copilot-cli.start-cli %}

content/copilot/how-tos/github-copilot-app/use-byok-models.md

@@ -1,6 +1,6 @@
 ---
-title: Using your own LLM models in the GitHub Copilot app
-shortTitle: Use your own model provider
+title: Adding LLM models to the GitHub Copilot app
+shortTitle: Add LLM models
 intro: 'Connect a model from an external provider of your choice by supplying your own API key, then use the model in agent sessions.'
 allowTitleToDifferFromFilename: true
 product: '{% data reusables.gated-features.github-app %}<br><a href="https://github.com/features/ai/github-app" target="_blank" class="btn btn-primary mt-3 mr-3 no-underline"><span>Download {% data variables.copilot.github_copilot_app %}</span> {% octicon "link-external" height:16 %}</a>'
@@ -15,7 +15,7 @@ category:
 > [!NOTE]
 > Support to use your own model provider in the {% data variables.copilot.github_copilot_app %} is in {% data variables.release-phases.public_preview %} and subject to change.
 
-You can configure the {% data variables.copilot.github_copilot_app %} to use your own LLM provider, also called BYOK (Bring Your Own Key), instead of {% data variables.product.github %}-hosted models. You can set up your model provider when you first open the app or later in app settings.
+You can configure the {% data variables.copilot.github_copilot_app %} to include models from an LLM provider of your choice—using BYOK (Bring Your Own Key)—in addition to the {% data variables.product.github %}-hosted models. You can set up your model provider when you first open the app or later in app settings.
 
 You must sign in with a {% data variables.product.github %} account to use the app, but you do not need a {% data variables.product.prodname_copilot_short %} plan if you use your own model provider. If you do have a {% data variables.product.prodname_copilot_short %} plan, you can use both your own model provider and {% data variables.product.github %}-hosted models in the same app.
 

content/copilot/tutorials/stack-ai-generated-code-in-pull-requests.md

@@ -10,9 +10,6 @@ category:
   - Team collaboration
 ---
 
-> [!NOTE]
-> Stacked pull requests are in {% data variables.release-phases.public_preview %} and subject to change.
-
 Large pull requests are difficult to review and create bottlenecks, especially when AI helps you generate a high volume of code in a short time. Review quality also degrades as pull request size increases. Reviewers may skim the result, miss issues, or procrastinate and leave the pull request until it grows stale and develops merge conflicts.
 
 Stacked pull requests keep large code changes reviewable. 

content/pull-requests/get-started/about-stacked-prs.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 ## About stacked pull requests
 
 Stacked pull requests are two or more pull requests in the same repository, where:

content/pull-requests/get-started/stacked-prs-quickstart.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 {% data reusables.pull_requests.pr-stack-invitation %}
 
 {% data reusables.pull_requests.pr-stack-definition %}

content/pull-requests/how-tos/create-pull-requests/creating-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Create stacked pull requests with the `gh stack` extension in {% data variables.product.prodname_cli %} or on the {% data variables.product.github %} website.  
 
 > [!NOTE]

content/pull-requests/how-tos/create-pull-requests/managing-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Create pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 As you iterate on a stack, you often need to make changes in a lower layer, rebase to keep a linear history, or restructure its branches. The `gh stack` extension in {% data variables.product.prodname_cli %} handles these tasks with cascading operations that update every affected branch. See [AUTOTITLE](/pull-requests/reference/stacked-prs-cli-commands).
 
 ## Making changes to a lower layer

content/pull-requests/how-tos/merge-and-close-pull-requests/merging-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Merge and close pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Stacked pull requests merge from the bottom (closest to the trunk) up. 
 
 * You can merge any number of pull requests at once, as long as they form a contiguous group starting from the lowest unmerged pull request. 
@@ -24,7 +22,7 @@ The merge box for a stacked pull request shows the status of the entire stack, n
 * The stack has a linear history.
 * The current pull request meets all branch protection requirements for the stack base, such as `main`.
 
-If the stack is not linear, for example, after changes were pushed to a lower branch or after the trunk moved ahead, a **Rebase stack** button will appear in the merge box and you'll need to rebase the stack before you can merge.
+If the stack is not linear, for example, after changes were pushed to a lower branch or after the trunk moved ahead, a **Rebase stack** button will appear in the merge box and you'll need to rebase the stack before you can merge. Rebasing the stack will generate signed commits, and retain approvals if a diff has not changed, even if you have the **dismiss stale approvals** rule enabled. 
 
 > [!NOTE]
 > * If you merge via the API and want to use stacked pull requests, you'll need use the asynchronous merge API for stacks. See [AUTOTITLE](/rest/pulls/pulls?apiVersion=2026-03-10#merge-a-pull-request-asynchronously).
@@ -35,7 +33,7 @@ If the stack is not linear, for example, after changes were pushed to a lower br
 Stacks fully support merge queues. All pull requests in the stack are added to the queue in the correct order. If a pull request is removed or ejected from the queue, all pull requests above it in the stack are also removed. 
 
 > [!NOTE]
-> To keep a stack together, the merge queue allows the merge group to exceed its configured maximum size by up to 50 percent. If the stack is too large to fit within that buffer, it will automatically be split across consecutive merge groups.
+> To keep a stack together, the merge queue allows the merge group to exceed its configured maximum size by up to 50 percent. If the stack is too large to fit within that buffer, it will automatically be put into the next merge group as a single unit.
 
 ## Merging from the bottom up
 

content/pull-requests/how-tos/merge-and-close-pull-requests/optimizing-ci-for-stacked-pull-requests.md

@@ -9,8 +9,6 @@ category:
   - Merge and close pull requests
 ---
 
-{% data reusables.public-preview.public-preview %}
-
 Every pull request in a stack is evaluated as if it targets the base of the stack, such as `main`. This keeps quality consistent across every layer, but it also means a workflow can run many times for a single stack. This article explains how workflows run for a stack and how to reduce redundant CI usage.
 
 ## How workflows run for a stack