How to make a received GitHub PR with changed history ff-mergeable?

Question

A user created a PR with a single commit in my repository on GitHub.

Since the PR, changes were pushed to the main repository, so the merge could not be fast-forward.

TL;DR

I pulled his branch, rebased a couple of times and pushed to origin, so the PR commit now has a different hash, and the GitHub PR was not automatically marked as pulled in.

---

I was working on a topic branch and fetched his master.

* 5977cb4 - (user/master) PR <user>
| * 857775e - (HEAD -> topic) topic commeit. <me>
| | * 871201e - (master) Local changes in master <me>
| |/  
| * f648f4e - (origin/master) Changes in origin <me>
|/  
* 3461bd2 - Initial commit <me>

and then rebased upon his master branch

➜  local git:(topic) git rebase user/master
First, rewinding head to replay your work on top of it...
Applying: Changes in origin
Applying: topic commeit.

* 1e2fe2e - (HEAD -> topic) topic commeit. <me>
* 1c7caa9 - Changes in origin <me>
* 5977cb4 - (user/master) PR <user>
| * 871201e - (master) Local changes in master <me>
| * f648f4e - (origin/master) Changes in origin <me>
|/  
* 3461bd2 - Initial commit <me>

and then rebased it on my master and ff-merged topic in order to push to origin:

➜  local git:(topic) git rebase master
First, rewinding head to replay your work on top of it...
Applying: PR
Applying: topic commeit.

➜  local git:(topic) git checkout master
Switched to branch 'master'
➜  local git:(master) git merge topic
Updating 871201e..836e09d
Fast-forward

And pushed it to origin:

* 836e09d - (HEAD -> master, origin/master, topic) topic commeit. <me>
* 46e591a - PR <user>
* 871201e - Local changes in master <me>
* f648f4e - Changes in origin <me>
| * 5977cb4 - (user/master) PR <user>
|/  
* 3461bd2 - Initial commit <me>

by now, the PR commit has a different hash and the GitHub PR did not pick it up.

Now, I cannot cleanly pull it in, as I already have the commit changes in history, only with a different hash.

I would prefer to have GitHub mark it as merged, so it does not appear as though I rejected the changes.

What should I instruct the user to do such that the PR will be fast-forward merge-able? Should he simply pull my master branch? What can I do in the future to handle such cases more cleanly?

Answer 1

Github's Pull Requests are never merged in a fast-forward way. That's by design, so it's clearly stated who approved the inclusion of those commits authored by a stranger.

From GitHub's Help Merging a pull request:

Pull requests are merged using the --no-ff option.

So you can merge the PR in a no-ff way, or cherry-pick the commit and close the PR. In both cases, the authorship will be intact, and a Thank you message in the PR is worth more than a Merged status for the contributor's point of view.

If you decide to merge the PR, you can ask the contributor to rebase her branch on top of the current master so the history doesn't diverge that much, but it may not be worth to introduce that bureaucracy to the workflow.

Keeping a clean history is great, but there are cases in which a clean history isn't a linear one - don't try to over-engineer it :)