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?
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.
pushing " upstream " means that your current branch B has remote/B has its upstream branch. Ie: branch. B. merge is set, when your are pushing the " upstream " branch. Ie: when pulling to B , git knows what branch to pull (as well as which remote repo: branch.B.remote )
default. Defines the action git push should take if no refspec is explicitly given. Possible values are: nothing – do not push anything (error out) unless a refspec is explicitly given.
Git push origin is usually used only where there are multiple remote repositories and you want to specify which remote repository should be used for the push. For a git push origin command: git push command updates remote references using local references by sending objects necessary to complete the given references.
In Git 2.0, the default is now the "simple" semantics, which pushes: only the current branch to the branch with the same name, and only when the current branch is set to integrate with that remote branch, if you are pushing to the same remote as you fetch from; or.
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 allen-master
or 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 development
and 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 development
or production
branch.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With