Olsson John <john.olsson@xxxxxxxxxxxxx> writes:
> The git checkout command actually complains about the case when
> you give it an empty string
>
> $ git checkout "" feature/foobar
> fatal: empty string is not a valid pathspec. please use . instead if you want to match all paths
I actually knew that somebody new will bring up the message from
"checkout", which special cases an empty parameter.
The reason why it gives an extra piece of guidance in this case is
not because an empty string is something that can often come from a
common mistake, like the "unset-variable-in-double-quotes" example
that started this thread.
An empty string as a pathspec element used to mean "everything in
the directory", but we deprecated that interpretation of an empty
string, and then turned it into an error when somebody tried to use
it. And that is why there is such a special case message. The
purpose of it is primarily to help those who learned Git in older
days and thought we still took "" as if it were ".".
So we do not give the same error message if you say
$ git checkout "no-such-file" feature/foobar
when there is no "no-such-file". "" _is_ special in that case, and
that is why we special case. For most other commands, it is not a
good model to follow.
"git fetch", "git pull", "git ls-remote" never took an initial empty
argument as something special that we later robbed its meaning and
turned into an error.
Thanks.
