This would just bring in changes as needed. So - my work flow is this, in the previous version of client, I would just create a new branch against by folk, add in the code changes, then create a PR against my fork. So essentially, my 'fork' is the 'master', even though it is a 'fork' and not the original repository. I forked the original repo ( ) to fix the bugs, and maintain the client which I have been doing for the last 2+ years. As a result there is no way to transfer ownership to me or even merge any PR or code to it. Thanks so much, and again I apologize that this is causing problems for - the original 'repo' - is unmaintained, unmanaged and the user is 100% non contactable. It'd be helpful for us to understand how you're using your fork and how it differs from our assumptions and what we've seen elsewhere. Would you mind describing your workflow to help us understand your use case better? We've heard from others that in most cases for forks that are maintained independently of the upstream repo, they usually break off entirely as their own repo instead of remaining a fork because the fork relationship no longer adds any value and GitHub generally assumes that forks are used for contributing back to the parent. So the previous behavior often would mean people working from forks in Desktop were starting new branches way out of date from the latest commits, and this was intended to help people ensure they're up to date when starting on a new branch. This was an intentional change in #7762 based on the vast majority of forks being used to contribute to the upstream branch. Hi thanks for the issue and really sorry the update caused problems with your workflow.