From d17019252716fe996f966adc66ee8497d1254dae Mon Sep 17 00:00:00 2001 From: Ali Nazzal Date: Tue, 26 Aug 2025 19:36:53 +0300 Subject: [PATCH 1/2] contributing: clarify when to update a branch vs avoid during review --- src/contributing.md | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 963bef3af..157dbbc13 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -154,13 +154,11 @@ The CI in rust-lang/rust applies your patches directly against the current maste not against the commit your branch is based on. This can lead to unexpected failures if your branch is outdated, even when there are no explicit merge conflicts. -Before submitting or updating a PR, make sure to update your branch -as mentioned [here](git.md#keeping-things-up-to-date) if it's significantly -behind the master branch (e.g., more than 100 commits behind). -This fetches the latest master branch and rebases your changes on top of it, -ensuring your PR is tested against the latest code. +Update your branch only when needed: when you have merge conflicts, upstream CI is broken and blocking your green PR, or a maintainer requests it. Avoid updating an already-green PR under review unless necessary. During review, make incremental commits to address feedback. Prefer to squash or rebase at the end, and do so when a reviewer requests it. -After rebasing, it's recommended to [run the relevant tests locally](tests/intro.md) to catch any issues before CI runs. +When updating, use `git push --force-with-lease` and leave a brief comment explaining what changed. Some repos prefer merging from `upstream/master` instead of rebasing; follow the project's conventions. See [keeping things up to date](git.md#keeping-things-up-to-date) for detailed instructions. + +After updating, run local checks (e.g., `mdbook build` for this repo) to catch issues before CI runs. ### r? From a44cd17a3b40e2f7f1d9e838553cf1d184847d63 Mon Sep 17 00:00:00 2001 From: Ali Nazzal Date: Tue, 26 Aug 2025 19:41:08 +0300 Subject: [PATCH 2/2] contributing: restore tests/intro.md link; avoid 'this repo' wording --- src/contributing.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index 157dbbc13..d0a32f71a 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -154,11 +154,11 @@ The CI in rust-lang/rust applies your patches directly against the current maste not against the commit your branch is based on. This can lead to unexpected failures if your branch is outdated, even when there are no explicit merge conflicts. -Update your branch only when needed: when you have merge conflicts, upstream CI is broken and blocking your green PR, or a maintainer requests it. Avoid updating an already-green PR under review unless necessary. During review, make incremental commits to address feedback. Prefer to squash or rebase at the end, and do so when a reviewer requests it. +Update your branch only when needed: when you have merge conflicts, upstream CI is broken and blocking your green PR, or a maintainer requests it. Avoid updating an already-green PR under review unless necessary. During review, make incremental commits to address feedback. Prefer to squash or rebase only at the end, or when a reviewer requests it. When updating, use `git push --force-with-lease` and leave a brief comment explaining what changed. Some repos prefer merging from `upstream/master` instead of rebasing; follow the project's conventions. See [keeping things up to date](git.md#keeping-things-up-to-date) for detailed instructions. -After updating, run local checks (e.g., `mdbook build` for this repo) to catch issues before CI runs. +After rebasing, it's recommended to [run the relevant tests locally](tests/intro.md) to catch any issues before CI runs. ### r?