From f748a4096eb82e903dc4e2629e21d1e999937972 Mon Sep 17 00:00:00 2001 From: Elliot Winkler Date: Wed, 1 Nov 2023 18:55:37 -0600 Subject: [PATCH] Tweak some more wording --- docs/pull-requests.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/pull-requests.md b/docs/pull-requests.md index ea72910..9daa96a 100644 --- a/docs/pull-requests.md +++ b/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.