You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rust follows a no merge policy, meaning, when you encounter merge conflicts you are expected to always rebase instead of merge. E.g. always use rebase when bringing the latest changes from the master branch to your feature branch. Also, please make sure that fixup commits are squashed into other related commits with meaningful commit messages.
However hermitcore/rust does contain a current merge commit. So I would suggest to drop that commit and rebase instead.
What is the current process for PRs regarding changes in stdlib? Should I open a PR against hermitcore/rust and once that's approved @stlankes opens a PR in rust-lang/rust?
The text was updated successfully, but these errors were encountered:
The branch hermit is my personal collection and contains merge commits. I avoid to create a PR from this branch. I always create a fresh branch from rust-lang/master, test my changes, create a PR to rust-lang and delete it, if the PR is accepted.
What is the current process for PRs regarding changes in stdlib? Should I open a PR against hermitcore/rust and once that's approved @stlankes opens a PR in rust-lang/rust?
Yeah, I think that this is a good solution. Just to review it from our side.
There is no issue section at hermitcore/rust so I'm opening this issue here.
Rust CONTRIBUTING.md states that
However hermitcore/rust does contain a current merge commit. So I would suggest to drop that commit and rebase instead.
What is the current process for PRs regarding changes in stdlib? Should I open a PR against hermitcore/rust and once that's approved @stlankes opens a PR in rust-lang/rust?
The text was updated successfully, but these errors were encountered: