From: Junio C Hamano <gitster@pobox•com>
To: Stefan Beller <sbeller@google•com>
Cc: git@vger•kernel.org, bmwill@google•com, peff@peff•net
Subject: Re: [PATCH] pathspec: give better message for submodule related pathspec error
Date: Sat, 31 Dec 2016 17:11:18 -0800 [thread overview]
Message-ID: <xmqqh95j60uh.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <20161229192908.32633-1-sbeller@google.com> (Stefan Beller's message of "Thu, 29 Dec 2016 11:29:08 -0800")
Stefan Beller <sbeller@google•com> writes:
> Every once in a while someone complains to the mailing list to have
> run into this weird assertion[1].
>
> The usual response from the mailing list is link to old discussions[2],
> and acknowledging the problem stating it is known.
>
> For now just improve the user visible error message.
Thans. judging from the date: header I take this is meant as v3 that
supersedes v2 done on Wednesday.
It is not clear in the above that what this thing is. Given that we
are de-asserting it, is the early part of the new code diagnosing an
end-user error (i.e. you gave me a pathspec but that extends into a
submodule which is a no-no)? The "was a submodule issue" comment
added is "this is an end-user mistake, there is nothing to fix in
the code"?
I take that the new "BUG" thing tells the Git developers that no
sane codepath should throw an pathspec_item that satisfies the
condition of the if() statement for non-submodules?
> diff --git a/pathspec.c b/pathspec.c
> index 22ca74a126..b446d79615 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -313,8 +313,23 @@ static unsigned prefix_pathspec(struct pathspec_item *item,
> }
>
> /* sanity checks, pathspec matchers assume these are sane */
> - assert(item->nowildcard_len <= item->len &&
> - item->prefix <= item->len);
> + if (item->nowildcard_len > item->len ||
> + item->prefix > item->len) {
> + /* Historically this always was a submodule issue */
> + for (i = 0; i < active_nr; i++) {
> + struct cache_entry *ce = active_cache[i];
> + int ce_len = ce_namelen(ce);
> + int len = ce_len < item->len ? ce_len : item->len;
> + if (!S_ISGITLINK(ce->ce_mode))
> + continue;
Computation of ce_len and len are better done after this check, no?
> + if (!memcmp(ce->name, item->match, len))
> + die (_("Pathspec '%s' is in submodule '%.*s'"),
> + item->original, ce_len, ce->name);
> + }
> + /* The error is a new unknown bug */
> + die ("BUG: item->nowildcard_len > item->len || item->prefix > item->len)");
> + }
> +
> return magic;
> }
>
> diff --git a/t/t6134-pathspec-in-submodule.sh b/t/t6134-pathspec-in-submodule.sh
> new file mode 100755
> index 0000000000..e62dbb7327
> --- /dev/null
> +++ b/t/t6134-pathspec-in-submodule.sh
> @@ -0,0 +1,33 @@
> +#!/bin/sh
> +
> +test_description='test case exclude pathspec'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup a submodule' '
> + test_commit 1 &&
> + git submodule add ./ sub &&
Is this adding our own project as its submodule?
It MIGHT be a handy hack when writing a test, but let's stop doing
that insanity. No sane project does that in real life, doesn't it?
Create a subdirectory, make it a repository, have a commit there and
bind that as our own submodule. That would be a more normal way to
start your own superproject and its submodule pair if they originate
together at the same place.
Better yet create a separate repository, have a commit there, and
then pull it in with "git submodule add && git submodule init" into
our repository. That would be the normal way to borrow somebody
else's project as a part of your own superproject.
> + git commit -a -m "add submodule" &&
> + git submodule deinit --all
> +'
> +
> +cat <<EOF >expect
> +fatal: Pathspec 'sub/a' is in submodule 'sub'
> +EOF
> +
> +test_expect_success 'error message for path inside submodule' '
> + echo a >sub/a &&
> + test_must_fail git add sub/a 2>actual &&
> + test_cmp expect actual
> +'
> +
> +cat <<EOF >expect
> +fatal: Pathspec '.' is in submodule 'sub'
> +EOF
> +
> +test_expect_success 'error message for path inside submodule from within submodule' '
> + test_must_fail git -C sub add . 2>actual &&
> + test_cmp expect actual
> +'
> +
> +test_done
next prev parent reply other threads:[~2017-01-01 1:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 19:29 [PATCH] pathspec: give better message for submodule related pathspec error Stefan Beller
2017-01-01 1:11 ` Junio C Hamano [this message]
2017-01-03 18:15 ` Stefan Beller
2017-01-04 1:23 ` Jeff King
-- strict thread matches above, loose matches on Subject: below --
2016-12-28 0:05 Stefan Beller
2016-12-28 5:58 ` Jeff King
2016-12-28 18:13 ` Brandon Williams
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=xmqqh95j60uh.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=bmwill@google$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=sbeller@google$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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