4

How does the following command:

git config remote.origin.push refs/heads/master:refs/heads/master

relate to the following command:

git config push.default <option>

(either with the --local or --global option)

where <option> is one of:

nothing
matching
upstream (formerly tracking)
current
simple

?

I think I understand the second config command, but I don't understand how the first command conditions/relates to the second. Here are some references that provide context behind this question:

Community
  • 1
  • 1
Amelio Vazquez-Reina
  • 91,494
  • 132
  • 359
  • 564

1 Answers1

8

When you run:

git push origin ...

whatever is set in remote.origin.push overrides whatever is set in push.default. More generally, if remote.name.push is not set (here name is origin), git falls back on push.default, and then if that is also not set, it falls back on the built-in defaults as described in your links.

(Edit: as noted in Breaking Benjamin's comment below and my reply to it, if there is a ... part that contains at least one refspec, the refspec overrides remote.origin.push. So remote.origin.push applies only when you name origin explicitly or implicitly on the command line and omit any and all refspecs on the command line as well. For example, git push with no arguments that discovers origin, or git push origin with no additional arguments, has Git look up your remote.origin.push setting and use it; but git push origin xyz does not use your remote.origin.push setting. Of course the ... part above can include more flags, so the correct question at this point is whether the ... part contains any refspecs.)

Note that:

git config --local na.me value

means the same thing as without --local. When setting values (as here) the --local, --global, and --file filename options control where the value is set, but --local is the default.

(When fetching values:

git config na.me

[or git config --get or git config --get-all or git config --get-regexp], the --local, etc, options restrict where git will read from, and without one it reads from all of them, with the "most local" overriding a "less local" if something is set in more than one place.)

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thanks! - When you said `git push origin ...`, the `...` would be the branch name (if provided), correct? – Amelio Vazquez-Reina Oct 21 '13 at 21:06
  • 1
    Yes (or arbitrary refspecs, e.g., `refs/tags/foo`, `:refs/deleteme`, etc). – torek Oct 21 '13 at 21:08
  • @torek , if I have mentioned `git push origin branchName` , then it will get resolved to `git push origin branchName:refs/heads/branchName`. how will then `remote.origin.push` come in picture ? – Number945 May 09 '18 at 10:44
  • 2
    The `git push` documentation states that `remote..push` comes into play only when you run `git push ` without a `` part. If you *do* supply a `` part, an empty destination part means to repeat the source part. Note, however, that an *unqualified* reference as in the `xyz` part of `git push origin xyz` does not necessarily translate to a *branch* name. One thing not clear to me is how it *does* translate in all cases (e.g., if you have both a branch `xyz` and a tag `xyz` but the remote has only a tag `xyz`). – torek May 09 '18 at 14:27