Dun Peal <dunpealer@xxxxxxxxx> writes:
> When I clone a remote that has a branch `foo`, then `git checkout foo
> --`, the path disamgiuator makes the operation fail. `git checkout
> foo` without the disambiguator works. Following that, when branch
> `foo` already exists, `git checkout foo --` works even with the
> disambiguator that caused it to fail previously.
I do not think there is any bug. You were being bitten by folks who tried
to be helpful for newbies by introducing a(n arguably confusing) special
case; I can see why this is confusing, though.
> $ git checkout foo --
> fatal: invalid reference: foo
Immediately after a clone you would have
refs/heads/master
refs/HEAD -> refs/heads/master
refs/remotes/origin/foo
refs/remotes/origin/whatever-else-you-have
...
and there is no commit that you can name with "foo" when asking git to
check out some paths out of, nor there is no branch that you can name with
"foo" when asking git to check out to work on it.
You can say 'origin/foo', though, in general.
> $ git checkout foo
> Branch foo set up to track remote branch foo from origin.
Asking to check out a branch "foo" in order to work on extending the
history of that branch, when there is _no_ "foo", has a special magic
invented by some folks to "help usability", if there is only one $remote
that has "foo" in it. In this case, you have refs/remotes/origin/foo but
no other refs/remotes/$frotz/foo, and this special magic kicks in.
git behaves as if you meant "git checkout -t -b foo origin/foo" but were
too lazy to type that yourself in this case.
> Switched to a new branch 'foo'
> $ git checkout master
> Switched to branch 'master'
> $ git checkout foo --
> Switched to branch 'foo'
This is referring to local branch "foo", there is nothing magic.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html