From 034cee9ed6a965bd379655969eeec9b5dc8f976e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Le=C3=B3n=20Orell=20Valerian=20Liehr?= Date: Sun, 14 Jan 2024 10:32:35 +0100 Subject: [PATCH] Mention label has-merge-commits --- src/contributing.md | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/src/contributing.md b/src/contributing.md index d6b9fc84..925b4d3d 100644 --- a/src/contributing.md +++ b/src/contributing.md @@ -243,7 +243,13 @@ The CI will also run tidy and will fail if tidy fails. Rust follows a _no merge-commit policy_, meaning, when you encounter merge conflicts you are expected to always rebase instead of merging. E.g. always use rebase when bringing the latest changes from the master branch to your feature -branch. +branch. If your PR contains merge commits, it will get marked as `has-merge-commits`. +Once you have removed the merge commits, e.g., through an interactive rebase, you +should remove the label again: + + @rustbot label -has-merge-commits + +See [this chapter][labeling] for more details. If you encounter merge conflicts or when a reviewer asks you to perform some changes, your PR will get marked as `S-waiting-on-author`. When you resolve @@ -251,8 +257,6 @@ them, you should use `@rustbot` to mark it as `S-waiting-on-review`: @rustbot label -S-waiting-on-author +S-waiting-on-review -See [this chapter][labeling] for more details. - GitHub allows [closing issues using keywords][closing-keywords]. This feature should be used to keep the issue tracker tidy. However, it is generally preferred to put the "closes #123" text in the PR description rather than the issue commit;