Why does git branch -t fail with “Not tracking: ambiguous information”?
When I try to create a new branch tracking a remote branch, I get this:
$ git branch -t test origin/foo
error: Not tracking: ambiguous information for ref refs/remotes/origin/foo
The source seems to somehow search for branches to track and throws me out because it finds less more than one, but I don’t exactly get what it’s looking for since I already told it what to track on the command line.
Can anybody tell me what’s going on and how to fix it?
I saw this also when I had two remote repo’s with the same (default) fetch pattern (
fetch = +refs/heads/*:refs/remotes/origin/*) and the same branches.
I still haven’t worked out how to fix it properly, since I want to continue to push/pull to both repo’s, but manually adding the info to the project’s
.git/config works, e.g.:
[branch "mybranch"] remote = origin merge = refs/heads/mybranch
because it finds less than one
Nope: because it finds more than one matching remote branch, which means the function
remote_find_tracking() returns more than one tracking branch for a given local branch ref.
some_remote_branch not already tracked by one of your local branches?
git config -l would allow you to check what you have currently have set up).
git branch -r can also help to list your current remote-tracking branches. )
remote branches, which I thought are something different that remote-tracking branches.
Wrong, as illustrated by this thread:
remote-branches are the “real” remote-tracking-branches. You don’t commit to them locally, they are essentially read-only copies of exactly what is happening in a remote repository.
If you try to ‘git-checkout’ a remote-tracking branch, you will get a detached HEAD.
A branch to which you may commit changes. Optionally, the branch can be configured to “follow” one of your remote-tracking branches. This means that a ‘
git-pull‘ without arguments (when your local branch is checked out), will automatically ‘
git-fetch‘ and then ‘
git-merge‘ the remote-tracking branch.
it’s the job of
git-fetchto update remote-tracking branches with any changes found in the remote repository.
git-fetchand then runs a
git-mergeto update the currently-checked-out branch.
The problem is, for git-merge:
When this happens,
git-mergemust decide which
remote-tracking-branchto merge into the currently checked out local branch.
You can set which
remote-tracking-branchwill be selected in this situation with the –track option.
--tracksets up a local following branch to refer to a remote’s branch, not to the tracking branch
remote_find_tracking() takes a single remote and a refspec with src filled, and returns the given refspec after filling its dst, if an appropriate tracking was configured for the remote, meaning git.
/* * For the given remote, reads the refspec's src and sets the other fields. */ int remote_find_tracking(struct remote *remote, struct refspec *refspec);
May be it considers it already has a local following branch matching
some_remote_branch. Do you have any local branch with that exact same name?
Or, the other way around: your current branch has a remote branch with a similar name, which makes it a natural candidate for any
git-merge: trying to make it track another remote branch would make the
git-merge unable to choose which local branch to update/merge with changes of a remote.
Got it! The problem was that I have previously set up a remote with
--mirror, for the purpose of having a backup / public copy of my repository.
If you run
git remote add --mirror <name> <url>
it does not only flag the remote as mirror (which is what I wanted for pushes), but also configures
remote.<mirror>.fetch option for the mirror to
+refs/*:refs/*, which means that all of your branches suddenly “track” your mirror repository and any attempt to create a tracking branch is going to fail.
(As an added bonus, running
git fetch <mirror> is going to overwrite all your refs with old ones from your backup repo.)
The solution that seems to fix this issue is setting
: (which, I hope, means “never fetch anything”). This apparently fixes the tracking issue and eliminates the deadly fetch.
I got in a situation like this, but I do not know how. The listing from
git branch -av showed me only a single remote tracking branch for the branch I cared about (
What I did to fix it was to use the hexadecimal commit hash instead of
git checkout -b dev abc123 git push -u origin dev
When I did the push with
-u Git said
Branch dev set up to track remote branch dev from origin. Subsequent pulls and pushes worked as I expected.
None of the other fixes mentioned here worked for me. The one that ended up working was this:
$ git branch -t test origin/test error: Not tracking: ambiguous information for ref refs/remotes/origin/test
After running the above, even though git complained, it did end up creating a local branch
test but no upstream set.
Now, I opened the
.git/config file (which did not have any record of a branch
test) and added the following manually:
[branch "test"] remote = origin merge = refs/heads/test
After which everything worked fine.