Why should I specify a branch on the command line for `git pull`?

You have closed off your one option (i.e., you refuse to set an upstream) so you are left with no option: you must specify the branch. Note that you can write your own tool that does this.

The answer to why this is the case is complicated, and philosophical, and up to the people who maintain Git. Fundamentally, though, we can look at these facts:

• In Git, the push verb is not the opposite of the pull verb. As far as there are opposites, they are push and fetch. (The pull verb means "fetch, then merge-or-rebase", more or less.)

• As close as they are, push and fetch are not symmetric. When you use git fetch remote you bring commits from another repository into your repository, and then set up remote-tracking names to point to the tip-most such commits. The other repository has some set of branches B₁...B_n, and for each such name, your repository now has an up-to-date remote/Bi.

  On the other hand, since you set your push.default to current, when you use git push remote, your Git sends any required commits for your current branch C, and then asks remote remote to set its branch C to point to that same commit. There's no qualifier inserted in front of C, no eugen/ for instance, to make it unique to you; you ask their Git to set their name C directly.

  Even if you used some other push setting, you would still, in general, ask the remote to set their own branch. The fetch command has this whole name-space dedicated to each remote: you set your refs/remotes/remote/renamed, not your own refs/heads/name. The push command has them set their refs/heads/name.

There's an assumption here built in to Git: fetch from many, push to one. That assumption does not have to hold true, but the syntaxes available, and the remote-tracking namespace system, is built to support it. When you step outside this system, you must use a somewhat clumsier syntax. It's your choice how to deal with this (Git has lots of tools).

If you only fetch from one and push to one, you wouldn't need named remotes at all (why bother with an origin if there's only one of them?). Git could even assume by default that the branch names will always be the same on the fetch-from and push-to, and make fetch and push work without requiring any upstream setting. Of course, that would limit you to fetch-from-one push-to-one.

If Git assumed a fetch from many, push to many system, it might have a way to do what you want. But it doesn't (assume this), so it doesn't (have a way to do what you want).