What is the difference between git push.default=current and push.default=upstream?
The man page for git-config lists these options for push.default:
nothing - do not push anything. matching - push all matching branches. All branches having the same name in both ends are considered to be matching. This is the default. upstream - push the current branch to its upstream branch. tracking - deprecated synonym for upstream. current - push the current branch to a branch of the same name.
In most cases I would assume that pushing to a branch’s upstream branch would be the same as pushing to a branch of the same name, since the upstream branch would normally have the same name, and since the branch of the same name (“current”) would normally (or always, by definition?) be upstream. So what’s the difference?
- How to delete something that was accidentally pushed
- git - can't push to remote, error 'fatal: Not a git repository'
- Safe force push procedure?
- Pushing local repository to server
- Git read updates before pulling
- Egit: Configure upstream for push and pull
UPDATE: The man page for git-config has been updated (as one would expect), so the distinctions made there may be a lot clearer now.
2 Solutions collect form web for “What is the difference between git push.default=current and push.default=upstream?”
You’ve summarized the difference in your question.
upstream pushes to the configured upstream branch, while
current assumes the upstream branch has the same name as the current local branch, and pushes to that specific name. In reality, there’s no reason to assume a local branch’s upstream tracking branch has the same name as the local branch itself.
For example, if you work in multiple repositories or across many shared developer remotes, you often end up tracking different forks of the same branch, such as
susan-master, both of which track the
master branch in Allen and Susan’s repos, respectively. In this case,
current would be the incorrect setting, because those branch names don’t exist on their remotes.
upstream, however, would work just fine.
A more practical example might be tracking both a
production repository. Your workflow might use a different mainline branch for each, but that might get confusing. Suppose you were a code integrator and wanted to track both repositories’
master branches separately.
git checkout -b production --track production/master git checkout -b development --track development/master
Now you’ve got two branches that track their respective repositories, neither of which use the
master naming convention at all. There’s little confusion about the branch names: They explicitly describe what they track. Nevertheless,
push.default = current wouldn’t make any sense as neither remote contains a
current will push the current branch to a branch with the same name on the remote repo.
upstream will push the current branch to the upstream branch.
The upstream branch is a branch which has been explicitly or implicitly defined as being upstream from your current branch. That means that push and pull by default will sync with this branch. The upstream branch may be in the same repo as the current branch itself. You can do interesting things like set up your local master branch as upstream from your local feature (topic) branch, and push and pull between them.
Implicit upstream setup is done through the
branch.autosetupmerge config value. You can find documentation in the
git config help page. Explicit upstream setup is done with the
-u option to the
git branch command. See the help page for details.