Git - What is the difference between push.default "matching" and "simple"

Question

I have been using git for a while now, but I have never had to set up a new remote repo myself and I have been curious on doing so. I have been reading tutorials and I am confused on how to get "git push" to work.

If I simply use git push it asks me to see up a default branch(?) to point to? What is the difference between these two options it supplies me with?

git config --global push.default matching
git config --global push.default simple

Matching just pushes whatever branches I have on my local repo, and if they don't match I have to then manually tell it to push whatever new local branches I have, correct? Is this best practice to use or is simple best?

possible duplicate of [Warning: push.default is unset; its implicit value is changing in Git 2.0](http://stackoverflow.com/questions/13148066/warning-push-default-is-unset-its-implicit-value-is-changing-in-git-2-0) — Trevor Boyd Smith, Nov 07 '14 at 13:20
Now, if only `pull.default` is available for updating all those branches locally — Nogurenn, Oct 09 '17 at 03:36

Lalit Sachdeva · Accepted Answer · 2023-03-26T13:04:20.263

411

git push can push all branches or a single one dependent on this configuration:

Push all branches

git config --global push.default matching

It will push all the branches to the remote branch and would merge them. If you don't want to push all branches, you can push the current branch if you fully specify its name, but this is much is not different from default.

Push only the current branch if its named upstream is identical

git config --global push.default simple

So, it's better, in my opinion, to use this option and push your code branch by branch. It's better to push branches manually and individually.

edited Mar 26 '23 at 13:04

answered Feb 18 '14 at 21:06

Lalit Sachdeva

6,469
2
19
25

25

I liked the `push.default current` from @UpAndAdam answer. Does not knew about it. – alanjds Jan 17 '15 at 16:40
4

Note that `simple` is no longer an option. In `1.7.8.4` (and earlier?) it results in an error when you try to push. but `current` is still available – sixty4bit Mar 10 '16 at 20:48
@sixty4bit: I am using git version 1.7.1. I am using `tracking` -> push the current branch to its upstream branch. – kevinarpe Feb 08 '17 at 06:45
@sixty4bit No, it got included in a later Version of Git i don't know in which but (1.7) is old as hell though, even for 2016. I wouldn't recommend using such old Versions at all. – Schmoudi Oct 17 '17 at 12:38
Downvoted. Sorry, but the linked page's description of `simple` doesn't make sense, contradicts this answer, and is incorrect - which makes this answer confusing. The linked page says `simple` "will push branches one by one. Mostly connected with current branch." Does that mean it will push the branches sequentially as opposed to in parallel? What does "mostly connected" mean? Then, the description for `simple` goes on to quote the description for `matching`, which one would think means the description for `matching` also applies to `simple`. But obviously that is not true. – tvanc Jun 11 '19 at 12:28
When push.default is set to 'matching', git will push local branches to the remote branches that already exist with the same name. Since Git 2.0, Git defaults to the more conservative 'simple' behavior, which only pushes the current branch to the corresponding remote branch that 'git pull' uses to update the current branch. – Marwan Salim Jul 17 '20 at 08:08
@sixty4bit as of git 2.21 `current` is still available. `tracking` is a deprecated synonym for `upstream` Simple is like upstream with added safety that it only works if the names are the same. This is really handy if you are 'forking' off an upstream branch and want to constantly keep synchronized with it by merges and rebases. – UpAndAdam Jul 27 '20 at 13:55
With this I still need to specify a branch for `pull`, even after `push` :( – Vitaly Zdanevich Jul 21 '22 at 08:35
typo? "...but this is much is not different from `default`." ? is not much different from ? – 463035818_is_not_an_ai Jan 18 '23 at 15:34

UpAndAdam · Answer 2 · 2014-11-20T16:55:17.510

From GIT documentation: Git Docs

Below gives the full information. In short, simple will only push the current working branch and even then only if it also has the same name on the remote. This is a very good setting for beginners and will become the default in GIT 2.0

Whereas matching will push all branches locally that have the same name on the remote. (Without regard to your current working branch ). This means potentially many different branches will be pushed, including those that you might not even want to share.

In my personal usage, I generally use a different option: current which pushes the current working branch, (because I always branch for any changes). But for a beginner I'd suggest simple

push.default
Defines the action git push should take if no refspec is explicitly given. Different values are well-suited for specific workflows; for instance, in a purely central workflow (i.e. the fetch source is equal to the push destination), upstream is probably what you want. Possible values are:

nothing - do not push anything (error out) unless a refspec is explicitly given. This is primarily meant for people who want to avoid mistakes by always being explicit.

current - push the current branch to update a branch with the same name on the receiving end. Works in both central and non-central workflows.

upstream - push the current branch back to the branch whose changes are usually integrated into the current branch (which is called @{upstream}). This mode only makes sense if you are pushing to the same repository you would normally pull from (i.e. central workflow).

simple - in centralized workflow, work like upstream with an added safety to refuse to push if the upstream branch's name is different from the local one.

When pushing to a remote that is different from the remote you normally pull from, work as current. This is the safest option and is suited for beginners.

This mode will become the default in Git 2.0.

matching - push all branches having the same name on both ends. This makes the repository you are pushing to remember the set of branches that will be pushed out (e.g. if you always push maint and master there and no other branches, the repository you push to will have these two branches, and your local maint and master will be pushed there).

To use this mode effectively, you have to make sure all the branches you would push out are ready to be pushed out before running git push, as the whole point of this mode is to allow you to push all of the branches in one go. If you usually finish work on only one branch and push out the result, while other branches are unfinished, this mode is not for you. Also this mode is not suitable for pushing into a shared central repository, as other people may add new branches there, or update the tip of existing branches outside your control.

This is currently the default, but Git 2.0 will change the default to simple.

yes, but I assume even with the push.default setting that if you do "$ git push *origin master*", it will only push the current branch to origin to the branch on origin with the same name...right? you should mention that there is also a default remote — Alexander Mills, Oct 21 '15 at 18:29
I'm not sure I understand what you are getting at. In ANY MODE if you say `git push origin master` it will do the same thing. The point of the modes and defaults is generally what happens when you simply say `git push` and you don't tell it a remote or a branch. What default setting? you mean the default setting of push.default? the default setting in which version of git... if you dont get it your comment is extremely vague. — UpAndAdam, Oct 21 '15 at 19:33
'push.default Defines the action git push should take if no refspec is explicitly given' if you say git push origin master you are giving it more information and it still might not do what you describe; depending on the refspec you set up.. https://git-scm.com/book/en/v2/Git-Internals-The-Refspec — UpAndAdam, Oct 21 '15 at 19:39
you may want to also see the difference between `simple` and `current` here https://stackoverflow.com/a/23918418/5506988 — Mark, Jan 06 '21 at 10:43

score 3 · Answer 3 · edited Jan 04 '16 at 16:44

Git v2.0 Release Notes

Backward compatibility notes

When git push [$there] does not say what to push, we have used the traditional "matching" semantics so far (all your branches were sent to the remote as long as there already are branches of the same name over there). 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
only the current branch to the branch with the same name, if you are pushing to a remote that is not where you usually fetch from.

You can use the configuration variable "push.default" to change this. If you are an old-timer who wants to keep using the "matching" semantics, you can set the variable to "matching", for example. Read the documentation for other possibilities.

When git add -u and git add -A are run inside a subdirectory without specifying which paths to add on the command line, they operate on the entire tree for consistency with git commit -a and other commands (these commands used to operate only on the current subdirectory). Say git add -u . or git add -A . if you want to limit the operation to the current directory.

git add <path> is the same as git add -A <path> now, so that git add dir/ will notice paths you removed from the directory and record the removal. In older versions of Git, git add <path> used to ignore removals. You can say git add --ignore-removal <path> to add only added or modified paths in <path>, if you really want to.

score 0 · Answer 4 · answered Aug 28 '23 at 17:40

There are now a big pile of options for this setting. Here's a chart of the differences:

Behaviour	`current`	`upstream`²	`simple`³	`matching`
Push checked-out branch	✔	✔	✔	✔
Push other branches				✔
Upstream branch must be configured		✔	✔
Upstream branch name must match	✔		✔	✔

_{¹ nothing requires all options to be specified on the CLI.}
_{² upstream has a deprecated alias, tracking.}
_{³ simple is the default, since Git v2.0.}

Git - What is the difference between push.default "matching" and "simple"

4 Answers4

Git v2.0 Release Notes

Backward compatibility notes

Linked