Re: Inconsistent behavior of the path disambiguator

Dun Peal [off-list ref] 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.