From: Junio C Hamano <gitster@pobox.com>
To: Olsson John <john.olsson@saabgroup.com>
Cc: "git@vger.kernel.org" <git@vger.kernel.org>
Subject: Re: [EXTERNAL] Re: Error handling when giving empty command line arguments
Date: Wed, 25 May 2022 08:46:10 -0700 [thread overview]
Message-ID: <xmqqy1ypaa4d.fsf@gitster.g> (raw)
In-Reply-To: <8767dbe0c22540a4ab3e18684aa7e030@saabgroup.com> (Olsson John's message of "Wed, 25 May 2022 07:32:18 +0000")
Olsson John <john.olsson@saabgroup.com> 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.
next prev parent reply other threads:[~2022-05-25 15:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-24 13:25 Error handling when giving empty command line arguments Olsson John
2022-05-24 22:51 ` Junio C Hamano
2022-05-25 7:32 ` [EXTERNAL] " Olsson John
2022-05-25 15:46 ` Junio C Hamano [this message]
2022-05-25 4:41 ` Kevin Daudt
2022-05-25 7:03 ` [EXTERNAL] " Olsson John
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqy1ypaa4d.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=john.olsson@saabgroup.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).