Is the remote branch actually called "master"?

Be careful - you have case mixing between local and remote branch!

Suppose you are in local branch downloadmanager now (git checkout downloadmanager)

You have next options:

1. Specify remote branch in pull/push commands every time (case sensitive):

   git pull origin DownloadManager

   or

   git pull origin downloadmanager:DownloadManager

2. Specify tracking branch on next push:

   git push -u origin DownloadManager

   (-u is a short form of --set-upstream)

   this will persist downloadmanager:DownloadManager link in config automatically (same result, as the next step).

3. Set in git config default remote tracking branch:

   git branch -u downloadmanager origin/DownloadManager

   (note, since git 1.8 for branch command -u is a short form of --set-upstream-to, which is a bit different from deprecated --set-upstream)

   or edit config manually (I prefer this way):

   git config --local -e

   -> This will open editor. Add block below (guess, after "master" block):

   [branch "downloadmanager"]
           remote = origin
           merge = refs/heads/DownloadManager
   

and after any of those steps you can use easily:

git pull

If you use TortoiseGit: RightClick on repo -> TortoiseGit -> Settings -> Git -> Edit local .git/config

Hi @johnwslongland 👋

Not a dumb question at all. Yes you can safely remove that fetch line from your .git/config. It’s forcing Git to fetch a branch that no longer exists, which is why git fetch upstream keeps failing. Either delete that line or reset the upstream remote (git remote remove upstream → git remote add upstream <repo-url>), then fetch again. That should resolve the error 👍

The problem in this case is that your remote ds does not have a branch named master. Probably they've switched to using main instead, but perhaps they just don't have either one. Note that there is nothing special about either name, except that people tend to use those as the initial name of the first branch they create. Any branch can be renamed at any time: the names are not significant.

Note that in Git, a branch name merely holds the hash ID of the last commit that Git should consider to be part of the branch. The two constraints on branch names are:

• they must meet the requirements spelled out in the git check-ref-format documentation;
• they must contain the hash ID of some existing commit.

This means that in a new, empty Git repository, with no commits in it, no branch names exist. Nonetheless, you are, in such a repository, "on" some branch. You're just on a branch that doesn't exist. Making the first commit creates the branch with that name—so until you make the first commit, you can change the name as much as you like: you're changing the name of the branch that doesn't exist.

Yesterday, upon the stair,
I met a man who wasn't there!
He wasn't there again today.
Oh how I wish he'd go away!
—William Hughes Mearns

Once you've created your first commit, your initial branch name now exists. You may now rename it, and/or create as many more branch names as you like, though all must select this same commit. As you add more commits to the repository, you can make the various branch names point to different commits, and/or add new branch names. The existing commits remain, and are findable—or not findable—by starting from some named commit and working backwards.

There are probably some commands to resolve it, but I would start by looking in your .git/config file for references to that branch, and removing them.