Can't do a checkout with multiple remotes

When you have only a single remote (let's call it origin) then when you type

git checkout foo

when foo doesn't exist but origin/foo does exist git will behave as though you typed the following

git checkout -b foo origin/foo

If you have multiple remotes, and foo does not exist locally but exists in 2 or more remotes then this behavior is suppressed.

You will need to explicitly create foo and instruct git what remote/branch you want it to track.

git checkout -b foo <remote>/foo


  1. when there is only one remote,the git checkout of a remote branch works perfectly fine.If the branch is not in the local machine,it checks for the branch in the git website and if the branch is there in the git website,it will download the branch into your local machine and then set it to track the branch in the branch in the git website(also called as remote)
  2. But when you add two remotes,git checkout of a remote branch using git checkout branch fails.
  3. This can be fixed by setting one of the remote as default.

  4. For doing this,add the below line to your gitconfig file.(Global git config file is usually located at ~/.gitconfig)

    [checkout]
    defaultRemote=origin

Git 2.19 will help, since "git checkout" and "git worktree add" learned to honor checkout.defaultRemote when auto-vivifying a local branch out of a remote tracking branch in a repository with multiple remotes that have tracking branches that share the same names.

See commit 8d7b558, commit ad8d510, commit 1c55055, commit 3c87aa9, commit e4d2d55, commit e417151, commit 17b44ae, commit c8cbf20 (05 Jun 2018) by Ævar Arnfjörð Bjarmason (avar).
(Merged by Junio C Hamano -- gitster -- in commit 50858ed, 02 Aug 2018)

Note: DWIM is "do what I mean", when a computer systems attempt to anticipate what users intend to do, correcting trivial errors automatically rather than blindly executing users' explicit but potentially incorrect inputs.
I have seen in with Git 2.16 remote format, and Git 2.13 checkout completion.

checkout & worktree: introduce checkout.defaultRemote

Introduce a checkout.defaultRemote setting which can be used to designate a remote to prefer (via checkout.defaultRemote=origin) when running e.g. "git checkout master" to mean origin/master, even though there's other remotes that have the "master" branch.

I want this because it's very handy to use this workflow to checkout a repository and create a topic branch, then get back to a "master" as retrieved from upstream:

(
   cd /tmp &&
   rm -rf tbdiff &&
   git clone [email protected]:trast/tbdiff.git &&
   cd tbdiff &&
   git branch -m topic &&
   git checkout master

)

That will output:

Branch 'master' set up to track remote branch 'master' from 'origin'.
Switched to a new branch 'master'

But as soon as a new remote is added (e.g. just to inspect something from someone else) the DWIMery goes away:

(
   cd /tmp &&
   rm -rf tbdiff &&
   git clone [email protected]:trast/tbdiff.git &&
   cd tbdiff &&
   git branch -m topic &&
   git remote add avar [email protected]:avar/tbdiff.git &&
   git fetch avar &&
   git checkout master

)

Will output (without the advice output added earlier in this series):

error: pathspec 'master' did not match any file(s) known to git.

The new checkout.defaultRemote config allows me to say that whenever that ambiguity comes up I'd like to prefer "origin", and it'll still work as though the only remote I had was "origin".

CodeManX does point out in the comments how to set that new option:

git config --add checkout.defaultRemote origin

(add --global if you want to set it globally)

Tags:

Git

Recent Posts