Git pull - default remote and branch using -u option - works with push but not pull

Question

I am on Git version 2.6.3, and get this message when just running

git pull

\"There is no tracking information for the current br

Answer 1

the -u option is not recognized on pull, only with push

my question is - is there a good reason for that?

Well... actually Git 2.24 (Q4 2019, 4 years later) will provide -u for git pull/git fetch!

Official reason:

"git fetch" learned "--set-upstream" option to help those who first clone from their private fork they intend to push to, add the true upstream via "git remote add" and then "git fetch" from it.

You can follow along the discussions here.

See commit 24bc1a1 (19 Aug 2019) by Corentin BOMPARD (``).
^{(Merged by Junio C Hamano -- gitster -- in commit 9437394, 09 Sep 2019)}

pull, fetch: add --set-upstream option

Add the --set-upstream option to git pull/fetch which lets the user set the upstream configuration (branch..merge and branch..remote) for the current branch.

A typical use-case is:

git clone http://example.com/my-public-fork

git remote add main http://example.com/project-main-repo git pull --set-upstream main master

or, instead of the last line:

git fetch --set-upstream main master

git merge # or git rebase

This is mostly equivalent to cloning project-main-repo (which sets upsteam) and then "git remote add" my-public-fork, but may feel more natural for people using a hosting system which allows forking from the web UI.

This functionality is analog to "git push --set-upstream".

---

Note: that last feature introduced a type, fixed with Git 2.25 (Q1 2020).

See commit 391c7e4 (31 Oct 2019) by Ralf Thielow (ralfth).
^{(Merged by Junio C Hamano -- gitster -- in commit 7ab2088, 01 Dec 2019)}

fetch.c: fix typo in a warning message

^{Signed-off-by: Ralf Thielow
Reviewed-by: Jonathan Nieder}

So it is not:

multiple branch detected, incompatible with --set-upstream

But:

multiple branches detected, incompatible with --set-upstream

---

Note: With Git 2.27 (Q2 2020), the documentation has been updated.

See commit 9c68873 (09 Mar 2020) by René Scharfe (rscharfe).
^{(Merged by Junio C Hamano -- gitster -- in commit ab8ef92, 25 Mar 2020)}

pull: document more passthru options

^{Signed-off-by: René Scharfe}

git pull accepts the options --dry-run, -p/--prune, --refmap, and -t/--tags since a32975f516 ("pull: pass git-fetch's options to git fetch", 2015-06-18, Git v2.6.0-rc0 -- merge listed in batch #0), -j/--jobs since 62104ba14a (submodules: allow parallel fetching, add tests and documentation, 2015-12-15, Git v2.8.0-rc0), and --set-upstream since 24bc1a1292 (pull, fetch: git add --set-upstream option, 2019-08-19, Git v2.24.0-rc0). Update its documentation to match.

---

Note: With Git 2.29 (Q4 2020), the --set-upstream option is clearer:

See commit 847b372 (12 Aug 2020) by Philippe Blain (phil-blain).
^{(Merged by Junio C Hamano -- gitster -- in commit ee356a8, 19 Aug 2020)}

fetch, pull doc: correct description of '--set-upstream'

^{Signed-off-by: Philippe Blain}

The '--set-upstream' option to git fetch^(man) (which is also accepted by git pull^(man) and passed through to the underlying git fetch^(man)) allows setting the upstream configuration for the current branch.

This was added in 24bc1a1292 (pull, fetch: add --set-upstream option, 2019-08-19, Git v2.24.0-rc0).

However, the documentation for that option describes its action as 'If the remote is fetched successfully, pull and add upstream (tracking) reference [...]', which is wrong because this option does not cause neither git fetch nor git pull to pull:

• git fetch^(man) does not pull and
• git pull^(man) always pulls.

Fix the description of that option.
If the remote is fetched successfully, add upstream

The documentation now includes:

If the remote is fetched successfully, add upstream (tracking) reference, used by argument-less git pull and other commands.

It removes the notion of pulling and then adding upstream.