a better error message when pull occurs on non-existent upstream branch

[tierninho]

I created a repo on dotcom with multiple branches, then cloned it on Desktop. I eventually deleted one of the branches on dotcom, and did a fetch on Desktop.

As expected, Desktop asked me to publish this branch to dotcom. However, I did a pull on the branch while still in the same status, and I got this error:

Your configuration specifies to merge with the ref 'refs/heads/tierninho-patch-1' from the remote, but no such ref was fetched.

Perhaps this can be rewritten in layman terms for the average end user to comprehend?

v0.0.36, OS X 10.11.5

[agisilaos]

👋Would love to start working on it. What's the best approach to start thinking about this issue? I remember that many error messages aren't defined in the desktop repo. 🤔

[shiftkey]

I remember that many error messages aren't defined in the desktop repo. 🤔

@agisilaos they're defined over here - https://github.com/desktop/dugite/blob/master/lib/errors.ts

Adding a new GitError enum value, and a GitErrorRegexes entry to map the error message to the new GitError enum is all that needs to be done there (along with a regression test to validate the change). https://github.com/desktop/dugite/pull/175 is a good example to follow along with.

[shiftkey]

Dropping help wanted from this issue because I want to call out a workflow that ended up being attempted in #6930 that we didn't expect:

Along with showing a better error message, the dialog lets the user push the branch again to create it on the remote.

This felt like a different context to how the user would trigger this problem - when trying to pull in changes from the upstream branch, which now doesn't exist - and a potentially different solution:

Along with showing a better error message, the dialog lets the user stop tracking the upstream branch.

Why this approach?

• Branches can be cleaned up on the GitHub remote as part of normal usage - e.g. after a pull request is merged
• Branches can also be manually removed through the UI
• This feels like an opportunity to clean up locally, rather than restore the branch on the remote

In #6930 I suggested that the option here could be to --unset-upstream on the current branch, which will put the push/pull button for the current branch back to a Publish Branch state. This feels more explicit and less magical to the end user, if we can get the message right to explain why the remote branch no longer exists.

I also want to point out that pruning merged branches is currently on beta and being tested for GitHub repositories, which will likely reduce the number of users who encounter this flow.