Is it possible to tell Github that my branch was merged into upstream master?

Question

I used my local branch feature to create a PR for a github repo (I don't have write access to it). Later I decided I want to separate its last commit into a standalone PR, so I moved feature one commit back:

git checkout feature
git branch feature2
git reset --hard @~
git push -f

The first PR is merged upstream, so now I want to create the second PR:

git checkout master
git pull upstream master
git push origin
git checkout feature2
git rebase master

Unfortunately, it turns out that git lacks the information that feature was merged into master. Therfore, it doesn't realize that the nearest common base of feature2 and master is very close: it's just feature. Instead, rebase goes back all the way to common base of feature and master as if they were never merged. As a result, git rebase master becomes unnecessarily messy.

Why did Github lose the information that feature was merged into master through an upstream PR? Is there any way to provide Github with that information?

In the end, I had to resort to:

git checkout master
git checkout -b feature2_new
git cherry-pick feature2

Luckily I only needed to take care of a single commit. And even with a single commit, I think that a merge with the true base (if git knew about it) would be better than the cherry-pick because git would be able to use its knowledge of history to resolve more conflicts automatically.

Note that if I were to merge feature into master locally instead of doing a github PR, no information would have been lost. Of course, then my master would not be in sync with the upstream repo, so it would be pointless.

Answer 1

To answer the questions as asked,

Is it possible to tell Github that my branch was merged into upstream master? [...] Why did Github lose the information that feature was merged into master through an upstream PR?

Yes, it's certainly possible to record the merge. That's usual.

Someone chose to tell git (and github) not to record this one, so the effects appeared on the upstream master branch without a trace of where they came from.

What you're looking at is the results of someone choosing to divorce the mainline history from the history you offered. Why they chose to do that, you'll have to find out from them. It's a common and widely-used option, for reasons any number of people will be very happy to opine about. Linearizing history looks nice but involves tradeoffs, there's downsides either way and different people and different situations will tilt the balance in their own ways.

Regardless, after fetching the result you've now got an unrecorded merge, which is fine, clean and dandy so long as you never try to merge subsequent work still based on the unrecorded parent.

What to do about it?

The option you chose, which could also and more flexibly (it handles multiple-commit feature1..feature2 histories) be full-spelled as

git rebase --onto master feature1 feature2

is generally cleanest: upstream abandoned your feature1 history, so you abandon it, rebasing your feature2 on the content they have now.

If for some reason you really don't want to abandon the feature1 history in your own repository -- maybe you've got more than just feature2 based off the old feature1 tip and the rebasing would start to get tedious -- you can also add a local record of the merge.

echo $(git rev-parse origin/master origin/master~ feature1) >>.git/info/grafts

This tells the local git that the current origin/master commit has as parents both its recorded first-parent commit and also the local feature1 commit. Since upstream has abandoned the feature1 commit and you haven't, all of git's machinery now works properly both here and upstream.

Different projects have different rules for what pull-request histories should be based on, some want everything based on some latest tip, others want everything based off a maintenance-base tag, others want bugfixes based on the commit that introduced the bug (I think this should be far more common). Some don't care much because everybody's so conversant with the code base that rebase-as-desired is still simplest.

But the important part here is that rebase-before-pushing is your last opportunity to be sure that what you're pushing is exactly right. It's an excellent habit to get into, and grafts work beautifully in that workflow.