Skip to content

contributing: clarify when to update a branch vs avoid during review #2554

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Aug 26, 2025
Merged

contributing: clarify when to update a branch vs avoid during review #2554

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d170192
contributing: clarify when to update a branch vs avoid during review
ali90h Aug 26, 2025
a44cd17
contributing: restore tests/intro.md link; avoid 'this repo' wording
ali90h Aug 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 3 additions & 5 deletions src/contributing.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -154,11 +154,9 @@ 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 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 rebasing, it's recommended to [run the relevant tests locally](tests/intro.md) to catch any issues before CI runs.

Expand Down