Merge pull request #57703 from github/repo-sync

Repo sync

Author: docs-bot

content/code-security/dependabot/working-with-dependabot/dependabot-options-reference.md

@@ -782,7 +782,7 @@ When `versioning-strategy` is defined, {% data variables.product.prodname_depend
 |--------|--------|
 | `auto` | Default behavior.|
 | `increase`| Always increase the minimum version requirement to match the new version. If a range already exists, typically this only increases the lower bound. |
-| `increase-if-necessary` | Leave the constraint if the original constraint allows the new version, otherwise, bump the constraint. |
+| `increase-if-necessary` | Leave the version requirement unchanged if it already allows the new release (Dependabot still updates the resolved version). Otherwise widen the requirement. |
 | `lockfile-only` | Only create pull requests to update lockfiles. Ignore any new versions that would require package manifest changes. |
 | `widen`| Widen the allowed version requirements to include both the new and old versions, when possible. Typically, this only increases the maximum allowed version requirement. |
 

content/contributing/style-guide-and-content-model/style-guide.md

@@ -1440,29 +1440,29 @@ The following example shows part of a table from [AUTOTITLE](/code-security/depe
 <td align=center>
 {% octicon "check" aria-label="Supported" %}
 </td>
-</td>
+
 <td align=center>
 {% octicon "x" aria-label="Not supported" %}
 </td>
 <td align=center>
 {% octicon "check" aria-label="Supported" %}
 </td>
-</td>
+
 <td align=left>Location of package manifests</td>
 </tr>
 <tr>
 <td style="text-align:left"><code>schedule.interval</code></td>
 <td align=center>
 {% octicon "check" aria-label="Supported" %}
 </td>
-</td>
+
 <td align=center>
 {% octicon "x" aria-label="Not supported" %}
 </td>
 <td align=center>
 {% octicon "check" aria-label="Supported" %}
 </td>
-</td>
+
 <td align=left>How often to check for updates</td>
 </tr>
 </tbody>

content/get-started/writing-on-github/working-with-advanced-formatting/autolinked-references-and-urls.md

@@ -77,6 +77,8 @@ When referencing a commit from a private repository inside of a commit message,
 
 By default, references generate a backlink. For example, manually linking to an issue in a pull request will automatically generate another link from the issue _back_ to the pull request.
 To avoid this behavior, you can use `redirect.github.com` instead of `github.com` when constructing the URL in your reference. If you do use a `redirect.github.com` URL in your reference link, no pop-up window will appear when hovering over it.
+> [!NOTE]
+> This method is not supported in {% data variables.product.prodname_ghe_cloud %} with Data Residency (`ghe.com`).
 
 ## Further reading
 

content/repositories/releasing-projects-on-github/linking-to-releases.md

@@ -17,7 +17,7 @@ topics:
 
 You can share a link to the latest release for a repository by adding `releases/latest` to the end of a repository's URL. For example, the URL for the latest release of `octo-org/octo-repo` is `https://{% data variables.product.product_url %}/octo-org/octo-repo/releases/latest`.
 
-To link directly to a download of your latest release asset that was manually uploaded, the suffix is `/releases/latest/download/asset-name.zip`.
+To link directly to a download of your latest release asset that was manually uploaded, the suffix is `/releases/download/latest/asset-name.zip`.
 
 ## Linking to older releases