Remove requests or suggestions about rebase and fixup contradictory to rust-highfive bot comment

src/contributing.md

@@ -144,8 +144,7 @@ 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.  Also, please make sure that fixup commits are squashed into other
-related commits with meaningful commit messages.
+branch.
 
 If you encounter merge conflicts, your PR will get marked as `S-waiting-on-author`.
 When you resolve them, you should use `@rustbot` to mark it as `S-waiting-on-review`.

src/git.md

@@ -238,8 +238,7 @@ rebase! Use `git push --force-with-lease` instead.
 
 ## Advanced Rebasing
 
-If your branch contains multiple consecutive rewrites of the same code, or if
-the rebase conflicts are extremely severe, you can use
+If your branch conflicts are extremely severe, you can use
 `git rebase --interactive master` to gain more control over the process. This
 allows you to choose to skip commits, edit the commits that you do not skip,
 change the order in which they are applied, or "squash" them into each other.
@@ -259,8 +258,7 @@ commit. Both the upside and downside of this is that it simplifies the history.
 On the one hand, you lose track of the steps in which changes were made, but
 the history becomes easier to work with.
 
-You also may want to squash just the last few commits together, possibly
-because they only represent "fixups" and not real changes. For example,
+You also may want to squash just the last few commits together. For example,
 `git rebase --interactive HEAD~2` will allow you to edit the two commits only.
 
 ## No-Merge Policy