Can't do a checkout with multiple remotes

Question

I have two remotes set up in my local git repo. One is the repo of an open-source project I'm contributing to, and the other is my fork of that repo.

It seems that I'm only able to check out stuff that I pull down from the origin remote. My normal method of grabbing a branch from a remote consists of

$ git fetch <remote> <branch>
$ git checkout <branch>

But this doesn't seem to work in my current situation.

$ git fetch my-remote my-branch
remote: Counting objects: 2297, done.
remote: Compressing objects: 100% (1951/1951), done.
remote: Total 2297 (delta 1044), reused 0 (delta 0), pack-reused 50
Receiving objects: 100% (2297/2297), 2.10 MiB | 1.59 MiB/s, done.
Resolving deltas: 100% (1045/1045), done.
From https://github.com/me/my-repo
 * branch            my-branch -> FETCH_HEAD
 * [new branch]      my-branch -> origin/my-branch
$ git checkout my-branch
error: pathspec 'my-branch' did not match any file(s) known to git.

Furthermore, the branch does not appear when I do git branch.

What's going on here?

Manisa

What is git branch --all telling you? – Brackish

With Git 2.19 (Q3 2018), you will avoid that error message, using the new config checkout.defaultRemote=origin. See my answer below. – Jesher

Answer 1

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

Kerenkeresan

Had a problem where I manually duplicated the remote in git .config file, as it was a mirror of another one, renaming the node. But I forgot to rename also de refs in fetch=, and that caused the issue. – Mixup

Answer 2

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)

Jesher

git config checkout.defaultRemote=origin failed for me in Git 2.28 with error: invalid key: checkout.defaultRemote=origin, but this worked: git config --add checkout.defaultRemote origin (add --global if you want to set it globally) – Giotto

@Giotto Thank you. I have included your comment in the answer for more visibility. – Jesher

git config --add checkout.defaultRemote upstream saved my life. Everytime I keep falling into this same hole, now I'll not, EVER! – Prolamine

Answer 3

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
   

Monroemonroy