Syncing a fork leaves me one commit ahead of upstream/master #22440
-
I have followed the instructions in https://help.github.com/articles/syncing-a-fork/ however my repository ends up being one commit ahead of the upstream/master each time I do it. If I resync with a quickly changing master I get a bunch of commits that only pertain to the resyncs. Then when I do want to create a pull request I get all of those commits in the pull. For an example, check out https://github.com/plestedr/Ada_Drivers_Library currently identical to the master but still 8 commits ahead. The only way I’ve found to work around this is to delete my repository and fork it again off of the upstream/master. That works but it seems like overkill. I tried rebasing on upstream/master, but that’s not working either. What am I missing? The online docs don’t address this topic so I think its something on my end. I get the same results every time. Hope y’all can point me to somewhere in the docs that can help. Bob |
Beta Was this translation helpful? Give feedback.
Replies: 8 comments 1 reply
-
For whatever reason, you are creating merge commits when you merge the upstream version of What you can do, if you’re certain you want your fork to exactly contain what is in the upstream repository is issue:
This will:
🚨 WARNING 🚨 This can potentially lose any commits that you have on your fork with changes unique to your fork that do not exist in the upstream repository. (But it sounds like that is what you want.) I hope that helps! |
Beta Was this translation helpful? Give feedback.
-
Thanks for the answer. This helped me resolve the issue the first time it occurred for me. I recently pushed some changes to an upstream repo and the changes got merged into that repo. But after it was merged, my fork was showing ‘1 commit ahead of [upstream], 1 commit behind [upstream]’, even though virtually everything was same between my fork and the upstream repo. So I followed the same solution thinking it would resolve this, and then it became ‘1 commit behind [upstream]’. It basically removed my own commits from my fork. So now, I did a fetch upstream before doing the reset again, and it shows the status correctly now. So, I think it would be safe to add fetch before reset like below…
If there’s anything apparently incorrect, please do let me know, so that I can completely avoid this issue altogether. |
Beta Was this translation helpful? Give feedback.
-
Yep, your instructions are probably slightly more complete. Thanks for sharing your solution with everyone! |
Beta Was this translation helpful? Give feedback.
-
How are you merging? If you are doing it using the github interface (with a pull request into your fork from upstream) then the merge will automatically use --no-ff, so it will create an extra comit. Source You should, on your machine, add a remote that points to upstream, then you should pull from that remote. This will create a fast-forward commit if you haven’t changed the master branch at all. Make sure that all commits you make to your fork are on new branches. If you make a commit to a branch that is actively developed on upstream (say master for example) and then upstream/master gets changed before your pull request gets merged into upstream, then your master and the upstream/master will have different histories. |
Beta Was this translation helpful? Give feedback.
-
My Github App solves your problem : ) 🤖 a GitHub App built with probot that keeps your repository up-to-date with upstream changes via automated PRs. |
Beta Was this translation helpful? Give feedback.
-
Hi, I know this is an older post but I was hoping to get some assistance. I followed your updates instructions however the final step git push --force gives me the error that I don’t have access to the repo? |
Beta Was this translation helpful? Give feedback.
-
git checkout master |
Beta Was this translation helpful? Give feedback.
-
Thanks for the solution. Works! Since github changed the default git checkout main |
Beta Was this translation helpful? Give feedback.
Thanks for the answer. This helped me resolve the issue the first time it occurred for me.
I recently pushed some changes to an upstream repo and the changes got merged into that repo. But after it was merged, my fork was showing ‘1 commit ahead of [upstream], 1 commit behind [upstream]’, even though virtually everything was same between my fork and the upstream repo. So I followed the same solution thinking it would resolve this, and then it became ‘1 commit behind [upstream]’. It basically removed my own commits from my fork. So now, I did a fetch upstream before doing the reset again, and it shows the status correctly now.
So, I think it would be safe to add fetch before reset like below…