Having a fork match the original repo when the original master branch can't be merged in?

The related questions that SO offer me only answer simple cases that can be solved with a pull - however, that doesn't work well, as you'll see below.

There's a repository I've forked, with just a master branch, and I've forked it, and I've worked in both my master, and a new branch of my own, rw-style. The owner of the forked repository's committed some of my changes but not others; the black dots on the top right below represent commits from both my master and rw-style branches.

I'm aware using the fork queue is not a good idea, so I'm staying away from it. Using git pull doe开发者_运维知识库s work, but it creates a conflict that I would then need to resolve, and it also results in duplicate history for my master branch, and that doesn't look particularly pretty.

I don't know any other solutions right now, so I'm currently considering just creating a patch from two commits that I haven't yet pushed, deleting my fork, creating it again from the original, and then applying my patches on top of it.

Is that the only solution?

You can rebase your fork on to master, via:

git rebase origin/master

(while in the fork branch). Alternatively you could also reset --hard your fork branch to your master branch, then cherry-pick every commit from your fork branch back in (but the rebase will be wayyy less work unless you're only forked by a few commits).

Once you've done that, you should be able to just merge your forked branch on to the master branch, as a fast-forward merge (no merge commits or anything). However, doing either of the above will mess up all of your hashes in your fork branch, so don't do this unless you're sure nothing else is referencing the fork branch.