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!

@SLaks The merge commit is the situation I have described. My question is why this occurs. — Tashus, Aug 31 '18 at 19:55
@Tashus: because that's the strategy upstream chose to merge your PR. It has a couple of other options (at least for intra-repo PRs), but it chose that one. — Sergio Tulentsev, Aug 31 '18 at 19:58
See my answer to https://stackoverflow.com/q/52020212/1256452 as well. — torek, Aug 31 '18 at 20:58

Romain Valeri · Answer 1 · 2018-08-31T20:11:38.573

As hinted at by SLaks in comment, the difference is the merge commit made on upstream/project.

When your pull request is accepted, branches are merged and a commit is made on upstream/project, but fork/project is not aware of this before you pull again from upstream.

When you pull, fork/project starts by fetching that new commit, then just fast-forwards without need for a merge. Only then are both trees identical.

About the strategy :

The very broad picture is that merge strategy (discussed here) is more noisy and a bit clunkier in terms of tree structure because of all the merge commits. In the other hand, rebase strategy is leanier but also trickier, with nasty situations to get out of if people use it carelessly.

To go further on the "strategy" part, there are a lot of comparisons with excellent answers already, just search along the lines of "merge/rebase debate".

I suppose what they're asking is, why did _upstream_ not merge with fast-forward? — Sergio Tulentsev, Aug 31 '18 at 20:02
@SergioTulentsev I was just getting ready to write a comment asking just that. — Tashus, Aug 31 '18 at 20:02

Sergio Tulentsev · Accepted Answer · 2018-08-31T20:13:27.830

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.

edited Aug 31 '18 at 20:13

answered Aug 31 '18 at 20:05

Sergio Tulentsev

226,338
43
373
367

1

Excellent point, I missed that in the question indeed. Also, didn't you mean *no-fast-forward* strategy is very useful for merging PRs? – Romain Valeri Aug 31 '18 at 20:08
Thank you both for your answers. Together you have answered my question. @RomainVALERI – Tashus Aug 31 '18 at 20:14
1

@Tashus: don't forget to mark an answer, btw. Whichever you deem more helpful. – Sergio Tulentsev Aug 31 '18 at 20:16
1

I'm in the habit of waiting 24 hours before accepting to allow everyone around the globe a chance to chime in. :) – Tashus Aug 31 '18 at 20:19

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

2 Answers2