Lets say there is a repository on GitHub called someweirdname/MyAwesomeRepo. I want to fork this repo, so I do. Now I have davidshq/MyAwesomeRepo.
I don’t get a chance to work on it for a few days and GitHub tells me in the interim 100 commits have been made to the upstream origin repo. So I create a pull request in my own repo (davidshq/MyAwesomeRepo) to pull in all the changes. I approve and merge the changes.
My (erroneous) expectation at this point is that davidshq/MyAwesomeRepo will now be exactly as someweirdname/MyAwesomeRepo – but it isn’t. Instead I’m one commit ahead (merging the pull request I just created).
Okay, slightly annoying but no big deal. But if I now make a change to my repo and attempt to create a pull request to the upstream origin repo GitHub adds in my merge commit as part of the pull request. Well, ain’t that annoying.
Now I know GitHub has an article on syncing forks, I’ve used it successfully in the past. But this time I didn’t.
I’m also sure there are multitudinous answers to this question floating around on the internet but I’m not quite sure how to succinctly query for them. What exactly is the problem I’m having and will Google understand it? Unlikely.
So I appeal to my fellow humans who have these incredibly powerful brains to assist me in finding the answer to my question(s):
- Why does creating a pull request of changes from the upstream origin via GitHub make the fork one commit ahead?
- Why does this seem not to happen when one performs the command line method offered in GitHub’s syncing forks documentation?
- What should one do once one has this aberrant commit (which, granted, is empty, but still shouldn’t be pushing an empty commit)?