1659

I've been using Git for a while now and have recently downloaded an update only to find this warning message come up when I try to push.

warning: push.default is unset; its implicit value is changing in 
Git 2.0 from 'matching' to 'simple'. To squelch this message 
and maintain the current behavior after the default changes, use: 

  git config --global push.default matching

To squelch this message and adopt the new behavior now, use: 

  git config --global push.default simple

I can obviously set it to one of the values mentioned, but what do they mean? What's the difference between simple and matching?

If I change it on one client will I need to do anything on other clients that I share repos with?

Alexander Shtang
  • 1,819
  • 4
  • 15
  • 24
Marko
  • 71,361
  • 28
  • 124
  • 158

5 Answers5

2166

It's explained in great detail in the docs, but I'll try to summarize:

  • matching means git push will push all your local branches to the ones with the same name on the remote. This makes it easy to accidentally push a branch you didn't intend to.

  • simple means git push will push only the current branch to the one that git pull would pull from, and also checks that their names match. This is a more intuitive behavior, which is why the default is getting changed to this.

This setting only affects the behavior of your local client, and can be overridden by explicitly specifying which branches you want to push on the command line. Other clients can have different settings, it only affects what happens when you don't specify which branches you want to push.

David Waller
  • 3,057
  • 4
  • 27
  • 28
hammar
  • 138,522
  • 17
  • 304
  • 385
  • 16
    Glad to know this change. When I was new to git I accidentally pushed all local branches thinking `git push` will push only current branch. – rahul286 Feb 28 '13 at 14:46
  • 2
    Is there any motive behind this change? – fotanus Jun 04 '13 at 12:16
  • 51
    The motive is that, empirically, most expect the new default behavior – Blake Miller Jun 15 '13 at 18:53
  • 2
    Is there a way to have `simple` configured in the global settings to being exchanged via dotfiles on all computers while having a computer specific `~/dotfiles/.git/config` setting `matching` for older version of Git which cannot handle `simple`? – JJD Jul 31 '13 at 23:27
  • 2
    @JJD: The repository's local `$repo/.git/config` file will always override other available gitconfig files, including `~/.gitconfig`. If you port your global config around, simply override the setting on an older repository with `git config push.default matching`. – Christopher Aug 02 '13 at 01:28
  • @Christopher That's exactly what I expected and what I did. However it does not work. As soon as I configure `git config --global push.default simple` Git 1.7.1 stops working and states this error: `error: Malformed value for push.default: simple`. – JJD Aug 02 '13 at 09:27
  • @JJD: After issuing that command, issue `git config push.default matching` (don't use the `--global` flag), and try it again. The repository's push default should override your global git config. – Christopher Aug 02 '13 at 12:34
  • 1
    @Christopher You got wrong. I set up both the local and the global config as you suggested. But it still fails. – JJD Aug 02 '13 at 13:14
  • 130
    It would be so much better to have your wonderfully clear summary in the warning message itself, rather than the instruction telling us to open the documentation and search for a string. – hertzsprung Aug 04 '13 at 17:18
  • 120
    _"It's explained very clearly in the docs"_ Sure it is if you end up on the right page, however the manual for [git push](https://www.kernel.org/pub/software/scm/git/docs/git-push.html) doesn't even have a mention of the word **simple** , which is probably who so many people ended up here instead. – Gerry Oct 30 '13 at 03:43
  • Plus Google is generally better at documenting a specific aspect of software (that I bother searching for) than that software itself is. Thanks SO! – Grault Nov 30 '13 at 02:47
  • 4
    Wait, so if you do `git config --global push.default simple` how would you override this and push push matching via a one-time command line – Michael K Madison Dec 27 '13 at 23:57
  • 36
    hammar's summary is a much more concise explanation than the git docs. – AJ. Jan 02 '14 at 16:01
  • 1
    @MichaelKMadison, `man git-push | grep match -B10` says `git push origin :` will do the trick for your once-only `matching` override of the `simple` config option. Works for me, but you have to specify the remote name (typically `origin`). A `git push --matching` would make more sense to me, but much of git is over my head anyway. – hobs Feb 26 '14 at 00:35
  • 4
    Actually, the git docs are as concise as hammar's explanation. However, hammar's explanation is much more useful to me because it explains **why** you'd choose one over the other in addition to explaining the behavior in a much more understandable way. As is too often the case, the git docs explain things for someone who is an expert in git. I read the git docs entry for `push.default` and was still lost. This answer makes things perfectly clear. – Michael Burr Apr 07 '14 at 21:21
  • 3
    WATCH OUT! Be careful if you set push.default=simple on your machine, and then issue `git push -f` on someone else's with `matching`. It will force push all remote branches! – funroll Jul 11 '14 at 21:38
  • 1
    "The motive is that, empirically, most expect the new default behavior" - Actually, 'simple' has some complexities to it (requiring the setting of upstream branches and such) that I don't think, empirically, anyone just "expects". The unmentioned in this error option of `current` seems like the behaviour people *actually* expect by default. – GlyphGryph Sep 09 '14 at 20:40
  • 2
    So what's the difference between `simple` and `upstream`? – Mark Reed Sep 19 '14 at 20:48
  • 1
    @MarkReed upstream is the setting I've just found I need. It's for when you don't want branches to have the same name as they do on the server (which I want with a complex subtree merging config) it means that the branch will be pushed to where you set it to track with 'git branch -u project/foo' – LovesTha Jan 08 '16 at 04:13
19

I realize this is an old post but as I just ran into the same issue and had trouble finding the answer I thought I'd add a bit.

So @hammar's answer is correct. Using push.default simple is, in a way, like configuring tracking on your branches so you don't need to specify remotes and branches when pushing and pulling. The matching option will push all branches to their corresponding counterparts on the default remote (which is the first one that was set up unless you've configured your repo otherwise).

One thing I hope others find useful in the future is that I was running Git 1.8 on OS X Mountain Lion and never saw this error. Upgrading to Mavericks is what suddenly made it show up (running git --version will show git version 1.8.3.4 (Apple Git-47) which I'd never seen until the update to the OS.

wgp
  • 1,147
  • 15
  • 15
  • 2
    I also started seeing this after upgrading to Mavericks. So I guess Git was upgraded at the same time as Mavericks, like you are implying. – Per Lundberg Nov 01 '13 at 07:52
8

If you get a message from git complaining about the value 'simple' in the configuration, check your git version.

After upgrading Xcode (on a Mac running Mountain Lion), which also upgraded git from 1.7.4.4 to 1.8.3.4, shells started before the upgrade were still running git 1.7.4.4 and complained about the value 'simple' for push.default in the global config.

The solution was to close the shells running the old version of git and use the new version.

grg
  • 5,023
  • 3
  • 34
  • 50
Tom Barron
  • 1,554
  • 18
  • 23
  • 13
    I am using a fresh Xcode install (git is version 1.8.5.2) and I was still having this error until I ran: `git config --global push.default simple` – Sam-Graham May 14 '14 at 18:36
2

I was wondering why I was getting that big warning message on Ubuntu 16.04 (which comes with Git 2.7.4), but not on Arch Linux. The reason is that the warning was removed in Git 2.8 (March 2016):

Across the transition at around Git version 2.0, the user used to get a pretty loud warning when running "git push" without setting push.default configuration variable. We no longer warn because the transition was completed a long time ago.

So you won't see the warning if you have Git 2.8 and later and don't need to set push.default unless you want to change the default 'simple' behavior.

Eugene Yarmash
  • 142,882
  • 41
  • 325
  • 378
0

Brought my answer over from other thread that may close as a duplicate...

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.

UpAndAdam
  • 4,515
  • 3
  • 28
  • 46