Why does a pull request result in the fork being behind the upstream?

Question

Suppose there is a GitHub repository named upstream/project. Let's say that I have a fork of it named fork/project. I commit some changes to fork/project and initiate a pull request to upstream/project. Once the pull request is accepted, why does fork/project become 1 commit behind upstream/project?

The code in the upstream repo now matches the code in my fork. Why must I pull again from the upstream repo just to end up in the same state? Couldn't the upstream repository be brought exactly in sync with the fork, rather than "overshooting" it?

I'm hoping for an answer that explains either the advantage that this system provides or the limitation that demands this workflow, whichever the case may be. Thanks!

Answer 1

I'm hoping for an answer that explains either the advantage that this system provides or the limitation that demands this workflow, whichever the case may be.

If what you're really asking is this:

why did upstream not merge with fast-forward?

Merge-commit/no-fast-forward strategy is very useful for merging PRs, because it allows reverting changes in just one step (because there's only one commit, regarless of how many were in the original branch). This alone is enough to make it the go-to strategy.