Re: "git checkout" resets modified files

[Junio C Hamano <gitster@pobox.com>]

Junio C Hamano <gitster@pobox.com> 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