-3

Version Control with Git says:

Pushes that use a refspec with just a source ref (i.e., with no destination ref) create a new branch in the remote repository:

$ cd ~/public_html
$ git checkout -b foo
Switched to a new branch "foo"
$ git push origin foo
Total 0 (delta 0), reused 0 (delta 0)
To /tmp/Depot/public_html
 * [new branch]      foo -> foo

Git Pocket Guide says:

If you have added a local branch of your own and want to start sharing it with others, use the -u option to have Git add your branch to the remote, and set up tracking for your local branch in the usual way, for example:

$ git push -u origin new-branch

After this initial setup you can use just git push on this branch, with no options or arguments, to push to the same remote.

What differences are between the things which they try to accomplish?

Why does the first not use -u, while the second does?

halfer
  • 18,701
  • 13
  • 79
  • 158
Tim
  • 1
  • 122
  • 314
  • 481

1 Answers1

3

If your question is about what the -u option to git push does, it's a duplicate: see Why do I have to "git push --set-upstream origin <branch>"? and How do I push a new local branch to a remote Git repository and track it too? This answer is about why a book from 2012 does not include an option that wasn't particularly necessary back then.

Assuming you mean this specific book, Version Control with Git, published in August 2012, the reason it does not suggest using git push -u is that it was published in 2012.

Git version 2.0 is dated:

$ git show v2.0.0
tag v2.0.0
Tagger: Junio C Hamano <gitster@pobox.com>
Date:   Wed May 28 11:04:29 2014 -0700

which, as you can see, is rather later than 2012. Now take a look at version 1.7.11:

$ git show v1.7.11
tag v1.7.11
Tagger: Junio C Hamano <gitster@pobox.com>
Date:   Sun Jun 17 14:07:26 2012 -0700

While this is 2012, it's late enough in 2012 that it was probably too late for the book.

It's not clear to me what Git Pocket Reference refers to, but probably it was written, or updated, after Git 2.0 came out.

Why 2.0 and 1.7.11 are relevant

Git version 1.7.11 introduced a new setting for push.default named simple. When using the simple setting, Git imposes a new requirement on defaulted git push operations: the upstream name of the branch you're pushing must match the local name. That is, if the upstream of your dev is origin/develop, git push with no refspec will fail. Meanwhile, if there is no upstream for your dev, git push with no refspec will also fail.

(When using the push.default setting named matching, both of these defaulted git push operations will run to completion, but will push your dev to dev on origin if it exists, or not push your dev at all if origin has no dev.)

If you, personally, left push.default unset, the setting is treated as matching in Git versions that predate 2.0, and as simple in Git versions 2.0 and higher. Since all or most of the book was written before Git 1.7.11 came out, it could hardly consider how the simple setting would affect git push. So it does not mention the -u option.

Modern descriptions will note that --set-upstream is important, so that future git push operations without refspecs will behave the way you would like, assuming you are using Git version 2.0 or later and have chosen a non-default push.default. So they will call for git push --set-upstream origin new-branch, or the same with the shorter -u spelling (which means the same thing in git push).

torek
  • 330,127
  • 43
  • 437
  • 552
  • Thanks. Does `git push -u` set up the remote branch as an upstream branch of the pushed local branch in `branch..merge`? `git push` also creates remote tracking branch for the upstream branch, and does it also set up its association between the upstream branch and the remote tracking branch in `remote..fetch`? – Tim Jan 16 '19 at 14:49
  • `git push -u ` first does the push as usual (which creates or updates the correct remote-tracking branch) and then acts like you ran `git branch --set-upstream-to`. So this means if the local branch you pushed had no upstream, now it has one, and if it had one before, now it has a new one (which may or may not match the one it had before). Consult the documentation for the `git branch --set-upstream-to` command to see precisely what that does. – torek Jan 16 '19 at 18:40