git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Ian Wienand <iwienand@redhat.com>
Cc: git@vger.kernel.org, Peter Kaestle <peter.kaestle@nokia.com>,
	Philippe Blain <levraiphilippeblain@gmail.com>
Subject: Re: [PATCH] submodule: separate out not-found and not-empty errors
Date: Wed, 17 Nov 2021 01:39:08 -0800	[thread overview]
Message-ID: <xmqqfsrv2kar.fsf@gitster.g> (raw)
In-Reply-To: YZQ5Zk0ItWvfr8sF@fedora19.localdomain

Ian Wienand <iwienand@redhat.com> writes:

>  			    !is_empty_dir(empty_submodule_path.buf)) {
>  				spf->result = 1;
> -				strbuf_addf(err,
> -					    _("Could not access submodule '%s'\n"),
> -					    ce->name);
> +				/* is_empty_dir also catches missing dirtectories, but report separately */
> +				if (!is_directory(empty_submodule_path.buf)) {

I was hoping that inspecting errno after is_empty_dir() returned
might be sufficient (of course, we need to clear errno before
calling is_empty_dir() if we go that route), but because this is an
error codepath that we do not need to optimize, a call to
is_directory() that incurs another system call would be fine.

> +				  strbuf_addf(err,
> +					      _("Submodule directory '%s' not found (incorrect --git-dir?)\n"),

"not found" is something the code definitely knows (eh, not quite,
but let's read on).  

But let's not make an uninformed guess.  This code didn't even check
if the user gave a --git-dir option.

If the user is advanced enough to have given "--git-dir", "not found"
should be sufficient to hint that the way the user specified the
repository location incorrectly, and a wrong "--git-dir" might be
one of the many things the user might suspect on their own.

Another problem with the message is !is_directory() can mean "there
is no filesystem entity at the path" (i.e. "submodule directory '%s'
does not exist") and it can also mean "there is a filesystem entity
at the path, but that is not a directory).  "not found" is not exactly
a good message to give in the latter case.

We are giving two messages here in this codepath.  For example, the
original one would have said something like:

	Could not access submodule 'foo'
	Submodule directory 'foo' is not empty

So I suspect that a more appropriate phrasing for the other one (the
new one you added) would be something like

	Could not access submodule 'foo'
	Path to the submodule 'foo' is not a directory

perhaps?

Thanks.


> +					      empty_submodule_path.buf);
> +				} else {
> +				  strbuf_addf(err,
> +					      _("Submodule directory '%s' is not empty\n"),
> +					      empty_submodule_path.buf);
> +				}
>  			}
>  			strbuf_release(&empty_submodule_path);
>  		}

  reply	other threads:[~2021-11-17  9:40 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-16 23:06 [PATCH] submodule: separate out not-found and not-empty errors Ian Wienand
2021-11-17  9:39 ` Junio C Hamano [this message]
2021-11-18  4:06   ` Ian Wienand

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqqfsrv2kar.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=iwienand@redhat.com \
    --cc=levraiphilippeblain@gmail.com \
    --cc=peter.kaestle@nokia.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.
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 NNTP newsgroup(s).