Tweak some more wording

docs/pull-requests.md

@@ -144,8 +144,8 @@ If you need to take over and merge someone else's branch, let them know so they
 Once you've created a pull request, avoid amending, rebasing, or otherwise altering the history of the branch, but push up each new change as a new commit instead. This has a few advantages:
 
 1. It aids reviewers in following your pull request over time. Keep in mind that they aren't as focused on your pull request as you are; they might look over your code, write some comments, leave, and then come back at a later time. The Conversation view of a pull request is an essential tool for reviewers to understand what happened while they were away. Usually, the timeline view preserves events in the same order in which they occurred. But rebasing the branch changes that order with regard to commits: specifically, if they were commingled with conversations before, now they are listed at the very end of the timeline. This can be extremely jarring.
-2. It ensures that conversations on a pull request stay as they are. Rebasing is not only confusing to reviewers because it jumbles the history of the pull request, but it can also be confusing to GitHub. If the commit that a conversation is connected to changes enough, GitHub may think that it is outdated and mark it as such. This is misleading and may cause the author of the pull request to start ignoring the conversation.
-3. It creates a smooth workflow with collaborators. If you're working with someone else but you change the history of the branch, they may have to now blow away their version of the branch and re-fetch it. This creates friction, causes frustration, and wastes time.
+2. It ensures that conversations on a pull request stay as they are. Rebasing is not only confusing to reviewers because it jumbles the history of the pull request, but it can also be confusing to GitHub. If a commit connected to a conversation changes enough, GitHub may think that the conversation is outdated and mark it as such. This is misleading and may cause the author of the pull request to start ignoring the conversation.
+3. It creates a smooth workflow with collaborators. If you're working with someone else but you change the history of the branch, they may have to blow away their version of the branch and re-fetch it. This creates friction, causes frustration, and wastes time.
 
 Make sure that when you click the button on GitHub to update a branch with its base branch, you do not choose the "rebase" option.