Re: [EXTERNAL] Re: Error handling when giving empty command line arguments

From: Junio C Hamano <gitster@pobox.com>
Date: May 25, 2022, 15:46 UTC
Message-ID: <xmqqy1ypaa4d.fsf@gitster.g>
In-Reply-To: <8767dbe0c22540a4ab3e18684aa7e030@saabgroup.com>

Olsson John <john.olsson@saabgroup.com> writes:

Show 5 quoted lines

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