Subject: Re: Error handling when giving empty command line arguments

From: Junio C Hamano <[email-masked]>
Date: Tue, 24 May 2022 15:51:52 -0700

Olsson John <[email-masked]> writes:

>   git fetch "${force}"
> ...
>   $ git fetch ""
>   fatal: no path specified; see 'git help pull' for valid url syntax
>   $
> ...
> That is, 'git fetch' does not check if the given string is an
> empty string before writing the error message. The empty string is
> completely unrelated to any path/URI and in this case it was not
> that helpful.

The user is not giving enough information to Git to allow it to tell
if "git fetch ''" it got came from any of these with unset variable:

	$ git fetch "$path"
	$ git fetch "$url"
	$ git fetch "$force"

because all Git sees is an empty string.

It is unfair to complain "is completely unrelated".  The user didn't
give enough information to even allow Git to tell if it is or is not
related.

The message _is_ complaining about a malformed URL.  You can fetch
from a local repository by specifying the path to the directory, or
you can fetch from a remote repository by specifying a URL.  Since
"" turns out to be neither a valid path or URL, the message hints
that it didn't see any path or valid url on the command line.  This
is coming from connect.c::parse_connect_url() that does not know
which end-user facing command ended up reaching there, so it is
understandable that it picked a command that ought to be more
familiar to users, i.e. "pull".  FWIW, 

	$ git ls-remote ""

would also give the same message that refers to "git help pull".

By the way, the "fatal" message talks about 'git help pull'; I
wonder if it should say "git help fetch" instead, although they will
refer to the same text included from Documentation/urls.txt.

Thanks.