Junio C Hamano <[email protected]> writes:
> I do not think this behaviour depends on the vintage of Git. An
> empty string as pathspec has always matched "everything in here"
> AFAIR.
Having said all that, I think the DWIM used by "git checkout" has
some room for improvement, namely, its "we didn't see a double-dash;
is it a ref or is it a pathspec?" disambiguation should become
similar to the revision parser's.
Notice that
$ git log ""
will error out, saying that an empty string does not name either a
revision or an existing path in the working tree. I think the same
"refusal due to ambiguity" should be in "git checkout" when the user
says
$ git checkout ""
Right now, when there is no double-dash, the code checks if the
first token X can be DWIMmed as a ref. It may either name an
existing branch X, or it may be a non-existing branch name, but
there is a single remotes/Y/X and the user is too lazy to say 'git
checkout -t -b remotes/Y/X X' and instead said 'git checkout X'.
And if the first token X cannot be DWIMmed as a ref according to the
above logic, unlike the revision parser, we do not check it (and all
the subsequent tokens) name existing filesystem entity.
I think we really should. With that, Steve's command line would
have correctly diagnosed as a liely error.
Of course, that still allows people to say
$ git checkout -- ""
if they really mean it, but they can type
$ git checkout -- :/
just as easily, so there is no big loss.
After following the existing code myself, I think this is a rather
easy low-hanging fruit for any aspiring Git hacker. Hint, hint...
> [Footnote]
>
> *1* Checking out a branch whose name is an empty string can be asked
> explicitly by disambiguating double-dash like this:
>
> $ git checkout "" --
>
> And it will be answered (correctly) with:
>
> fatal: invalid reference
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
