> So, I do not mind #2 described as a separate step. Conceptually, it > is between "create a list of all commits in the range and filter out > what have already been applied" and "create a list of all commits > that are not in the upstream yet". We may be able to rephrase "all > new commits on your current branch" somewhat to make it unnecessary > to describe #2, though. If we are willing to stop talking about > "This is the same set of ...", then the description becomes very > simple: To me it feels relevant that `git rebase` is using two separate mechanisms to compare commits: the sha and (I think?) what `git patch-id` does. As a user it feels like an important distinction because normally when I look at my git commits I only use the sha (via something like `git log --graph`) to see what the new commits on a branch are. Maybe the second part can be rephrased like this to emphasize that it's using a different mechanism than the SHA: > 2. Check whether any of those commits contain the same changes (according to `git patch-id`) as a commit already in `<upstream>` and remove them from the list. > The line is getting overly long here and a few lines below. If your > editor has the feature, tell it to auto-wrap at around 66-72 column. Will fix, and I'll add a pre-commit hook to check for that. > Force-create-branch while checking out is `git checkout -B > <branch>`, not -C. Will fix.
