为什么我要在命令行上为`git pull`指定一个分支?

时间:2018-05-28 16:03:29

标签: git git-config

我不想设置默认的原始服务器,也不想为分支设置上游。

对于push命令,我已将push.default=current配置为能够运行:

git push origin

此外,我希望能够运行:

git pull origin

但是得到错误:

You asked to pull from the remote 'origin', but did not specify
a branch. Because this is not the default configured remote
for your current branch, you must specify a branch on the command line.

如何绕过此错误消息?

1 个答案:

答案 0 :(得分:3)

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 B1...Bn, 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).