0

git fetch origin doesn't get the new branch, and thus --track always fails, no matter what I try.

https://gist.github.com/dubslow/dab61346cc06d6b9cf7b

That's ^ everything I've tried. You'll note that I tried all the commands in the related question "Cannot update paths and switch to branch at the same time", but still no success. I have no idea what is going on.

Edit: With this new local branch, I tried to push to my own remote, but got this confusing message:

bill@Gravemind⌚1643 ~/qtox/libs/libtoxcore-latest ∰∂ git remote add mine ssh://git@github.com/dubslow/toxcore.git
bill@Gravemind⌚1644 ~/qtox/libs/libtoxcore-latest ∰∂ git push mine new_api
Counting objects: 566, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (461/461), done.
Writing objects: 100% (566/566), 549.87 KiB | 0 bytes/s, done.
Total 566 (delta 302), reused 260 (delta 102)
To ssh://git@github.com/dubslow/toxcore.git
 ! [remote rejected] new_api -> new_api (shallow update not allowed)
error: failed to push some refs to 'ssh://git@github.com/dubslow/toxcore.git'
bill@Gravemind⌚1644 ~/qtox/libs/libtoxcore-latest ∰∂ git push mine +new_api
Counting objects: 566, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (461/461), done.
Writing objects: 100% (566/566), 549.87 KiB | 0 bytes/s, done.
Total 566 (delta 302), reused 260 (delta 102)
To ssh://git@github.com/dubslow/toxcore.git
 ! [remote rejected] new_api -> new_api (shallow update not allowed)
error: failed to push some refs to 'ssh://git@github.com/dubslow/toxcore.git'

Edit: As Andrew C points out, those error messages meant the repo was a shallow clone, and I had totally forgotten, and the error messages were rather useless (except for when I tried to push, and those were only sort of useful to someone more experienced with git).

Cœur
  • 37,241
  • 25
  • 195
  • 267
Dubslow
  • 553
  • 2
  • 6
  • 15
  • What does `git --version` report? Do you have multiple remotes? – Andrew C Feb 13 '15 at 23:42
  • git --version git version 2.1.4 I only have `origin` and the one I added in the shell log above. – Dubslow Feb 14 '15 at 00:20
  • 1
    `git checkout ` will only a create a branch if it exists on a single origin. Otherwise you need to explicitly specify where to track from `git checkout -b origin/`. I would suggest you don't use shallow clones. – Andrew C Feb 14 '15 at 01:15
  • Hollllllyyyyy crap I forgot it was a shallow clone. This was created by a script by a downstream project, and I totally forgot that we changed the script to make shallow clones. Since previously they weren't, I had totally forgotten that when I reran the script for some unrelated testing, the new clone was shallow... now `git checkout --track origin/new_api` works as advertised by the docs. Thanks. – Dubslow Feb 14 '15 at 04:07
  • @Dubslow: please don't put `[SOLVED]` in your title. If AndrewC helped you, he should write an answer that you could accept. Afterwards, revert your changes introduced with http://stackoverflow.com/revisions/28509967/3. This is how we handle things here. – eckes Apr 25 '16 at 10:10
  • 1
    @AndrewC: the edit http://stackoverflow.com/revisions/28509967/3 by OP indicates that your comment was helpful for him and suits as answer. Please go ahead and make your comment an answer so that OP could accept it. – eckes Apr 25 '16 at 10:11

2 Answers2

2

This syntax

git checkout <branch>

When <branch> does not already exist will only work if <branch> exists on a single remote. If you have multiple remotes you need explicitly say which remote to track from with

git checkout -b <branch> <remote>/<branch>

This part of your error message

(shallow update not allowed)

Suggests you have a shallow clone, which can cause all kinds of strange behavior.

Andrew C
  • 13,845
  • 6
  • 50
  • 57
0

A simple git checkout new_api should work, assuming you don't have a local branch already of that name. The local ref you (accidentally) created of the same name will conflict, so delete it first with git branch -d new_api.

git checkout <branch>
   To prepare for working on <branch>, switch to it by updating
   the index and the files in the working tree, and by pointing HEAD at
   the branch. Local modifications to the files in the working tree are
   kept, so that they can be committed to the <branch>.

   If <branch> is not found but there does exist a tracking branch in
   exactly one remote (call it <remote>) with a matching name,
   treat as equivalent to

       $ git checkout -b <branch> --track <remote>/<branch>
engineerC
  • 2,808
  • 17
  • 31