I forked a project on GitHub, pushed some changes, and opened a pull request. The maintainer signed-off and applied the changes in a new commit (rather than merging my commit), and so the commit graph looked like this:
* 03a0687 (origin/master) frotz: Corrected MAN_PREFIX
| * 11d3e98 (HEAD, master, jleedev/master) frotz: Corrected MAN_PREFIX
|/
* 9c3dd1a yajl: use direct patch from Github.
Obviously, I have to either rebase or force-update my local branch. Do I then have to force-push to my fork on GitHub? I’m mainly asking because force-updating should not be automatic. Is this the standard thing to do when your changes are cherry-picked by the maintainer?
The simplest thing to do is just always work on topic branches. That way your forks master branch always looks like upstream so that once upstream includes your changes you always do the same thing, just delete your topic branch.
If upstream merges your changes, your master and topic branch both contain the same commits and you can safely delete the topic branch. If upstream cherry-picks your commits then after verifying the changes made it to upstream you can just delete the topic branch.
The other major benefit of this is that you can easily rebase your topic branch against master. Sometimes if a patch cannot be applied upstream without manual conflict resolution they will ask you to rebase or merge and do the conflict resolution yourself, since its your code and you know more about it. I also suspect they cherry-picked your commit because they had commited after you made the fork and did not want to introduce a merge commit for only a small amount of commits. By cherry-picking they kept their history more linear and cleaner. If you had rebased often, it might have only been a fast-forward merge for them and they wouldn’t need to cherry-pick.
As for your question of what to do right now, force updating your local branch and then force pushing back to your fork is the only real option you have.