Re: Error handling when giving empty command line arguments

From: Junio C Hamano <gitster@pobox.com>
Date: May 24, 2022, 22:51 UTC
Message-ID: <xmqq35gyee7r.fsf@gitster.g>
In-Reply-To: <dc08a8ee5ed64850872fd6529d1462e1@saabgroup.com>

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

Show 10 quoted lines

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