Re: "git checkout" resets modified files

Junio C Hamano <gitster@pobox.com> writes:

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...