git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Duy Nguyen <pclouds@gmail.com>
To: Brandon Williams <bmwill@google.com>
Cc: Git Mailing List <git@vger.kernel.org>,
	Stefan Beller <sbeller@google.com>
Subject: Re: [PATCH 1/5] grep: illustrate bug when recursing with relative pathspec
Date: Sun, 26 Feb 2017 16:53:55 +0700	[thread overview]
Message-ID: <CACsJy8Df6hhTzx5BNx385T4cuCg5w3nvOioXB=q+NCoW9kA6_w@mail.gmail.com> (raw)
In-Reply-To: <20170224235100.52627-2-bmwill@google.com>

On Sat, Feb 25, 2017 at 6:50 AM, Brandon Williams <bmwill@google.com> wrote:
> When using the --recurse-submodules flag with a relative pathspec which
> includes "..", an error is produced inside the child process spawned for
> a submodule.  When creating the pathspec struct in the child, the ".."
> is interpreted to mean "go up a directory" which causes an error stating
> that the path ".." is outside of the repository.
>
> While it is true that ".." is outside the scope of the submodule, it is
> confusing to a user who originally invoked the command where ".." was
> indeed still inside the scope of the superproject.  Since the child
> process luanched for the submodule has some context that it is operating

s/luanched/launched/

I would prefer 1/5 t to be merged with 3/5 though. The problem
description is very light there, and the test demonstration in the
diff is simply switching from failure to success, which forces the
reader to come back here. It's easier to find here now, but it'll be a
bit harder when it enters master and we have to read it from git-log,
I think.

I'm still munching through the super-prefix patches. From how you
changed match_pathspec call in 0281e487fd (grep: optionally recurse
into submodules - 2016-12-16), I guess pathspecs should be handled
with super-prefix instead of the submodule's prefix (which is empty
anyway, I guess). The right solution wrt. handling relative paths may
be teach pathspec about super-prefix (and even original super's cwd)
then let it processes path in supermodule's context.

Does it handle relative paths with wildcards correctly btw? Ones that
cross submodules? I have a feeling it doesn't, but I haven't seen how
exactly super-prefix works yet.

There's another problem with passing pathspec from one process to
another. The issue with preserving the prefix, see 233c3e6c59
(parse_pathspec: preserve prefix length via PATHSPEC_PREFIX_ORIGIN -
2013-07-14). :(icase) needs this because given a path
"<prefix>/foobar", only the "foobar" part is considered case
insensitive, the prefix part is always case-sensitive. For example, if
you have 4 paths "abc/def", "abc/DEF", "ABC/def" and "ABC/DEF" and are
standing at "abc", you would want ":(icase)def" to match the first two
only, not all of them.

> underneath a superproject, this error could be avoided.
>
> Signed-off-by: Brandon Williams <bmwill@google.com>
> ---
>  t/t7814-grep-recurse-submodules.sh | 42 ++++++++++++++++++++++++++++++++++++++
>  1 file changed, 42 insertions(+)
>
> diff --git a/t/t7814-grep-recurse-submodules.sh b/t/t7814-grep-recurse-submodules.sh
> index 67247a01d..418ba68fe 100755
> --- a/t/t7814-grep-recurse-submodules.sh
> +++ b/t/t7814-grep-recurse-submodules.sh
> @@ -227,6 +227,48 @@ test_expect_success 'grep history with moved submoules' '
>         test_cmp expect actual
>  '
>
> +test_expect_failure 'grep using relative path' '
> +       test_when_finished "rm -rf parent sub" &&
> +       git init sub &&
> +       echo "foobar" >sub/file &&
> +       git -C sub add file &&
> +       git -C sub commit -m "add file" &&
> +
> +       git init parent &&
> +       echo "foobar" >parent/file &&
> +       git -C parent add file &&
> +       mkdir parent/src &&
> +       echo "foobar" >parent/src/file2 &&
> +       git -C parent add src/file2 &&
> +       git -C parent submodule add ../sub &&
> +       git -C parent commit -m "add files and submodule" &&
> +
> +       # From top works
> +       cat >expect <<-\EOF &&
> +       file:foobar
> +       src/file2:foobar
> +       sub/file:foobar
> +       EOF
> +       git -C parent grep --recurse-submodules -e "foobar" >actual &&
> +       test_cmp expect actual &&
> +
> +       # Relative path to top errors out

After 3/5, it's not "errors out" any more, is it?

> +       cat >expect <<-\EOF &&
> +       ../file:foobar
> +       file2:foobar
> +       ../sub/file:foobar
> +       EOF
> +       git -C parent/src grep --recurse-submodules -e "foobar" -- .. >actual &&
> +       test_cmp expect actual &&
> +
> +       # Relative path to submodule errors out

ditto

> +       cat >expect <<-\EOF &&
> +       ../sub/file:foobar
> +       EOF
> +       git -C parent/src grep --recurse-submodules -e "foobar" -- ../sub >actual &&
> +       test_cmp expect actual
> +'
> +
>  test_incompatible_with_recurse_submodules ()
>  {
>         test_expect_success "--recurse-submodules and $1 are incompatible" "
> --
> 2.11.0.483.g087da7b7c-goog
>



-- 
Duy

  reply	other threads:[~2017-02-26 10:03 UTC|newest]

Thread overview: 48+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-24 23:50 [PATCH 0/5] recursing submodules with relative pathspec (grep and ls-files) Brandon Williams
2017-02-24 23:50 ` [PATCH 1/5] grep: illustrate bug when recursing with relative pathspec Brandon Williams
2017-02-26  9:53   ` Duy Nguyen [this message]
2017-02-27 18:14     ` Brandon Williams
2017-02-24 23:50 ` [PATCH 2/5] pathspec: add PATHSPEC_FROMROOT flag Brandon Williams
2017-02-25  0:31   ` Stefan Beller
2017-02-24 23:50 ` [PATCH 3/5] grep: fix bug when recuring with relative pathspec Brandon Williams
2017-02-28 21:04   ` Junio C Hamano
2017-03-02 18:00     ` Brandon Williams
2017-02-24 23:50 ` [PATCH 4/5] ls-files: illustrate bug when recursing " Brandon Williams
2017-02-24 23:51 ` [PATCH 5/5] ls-files: fix bug when recuring " Brandon Williams
2017-02-28 21:07   ` Junio C Hamano
2017-03-02 18:01     ` Brandon Williams
2017-02-27 17:52 ` [PATCH 0/5] recursing submodules with relative pathspec (grep and ls-files) Brandon Williams
2017-03-06 23:07 ` [RFC PATCH] grep: fix bug when recursing with relative pathspec Brandon Williams
2017-03-14 22:10 ` [PATCH v2 0/4] recursing submodules with relative pathspec (grep and ls-files) Brandon Williams
2017-03-14 22:10   ` [PATCH v2 1/4] grep: fix help text typo Brandon Williams
2017-03-14 22:49     ` Stefan Beller
2017-03-15  0:20       ` Brandon Williams
2017-03-14 22:10   ` [PATCH v2 2/4] setup: allow for prefix to be passed to git commands Brandon Williams
2017-03-14 22:28     ` Johannes Schindelin
2017-03-14 22:35       ` Brandon Williams
2017-03-14 22:10   ` [PATCH v2 3/4] grep: fix bug when recursing with relative pathspec Brandon Williams
2017-03-14 23:03     ` Stefan Beller
2017-03-14 22:11   ` [PATCH v2 4/4] ls-files: " Brandon Williams
2017-03-14 23:06     ` Stefan Beller
2017-03-15 17:02       ` Brandon Williams
2017-03-17 17:22   ` [PATCH v3 0/5] recursing submodules with relative pathspec (grep and ls-files) Brandon Williams
2017-03-17 17:22     ` [PATCH v3 1/5] grep: fix help text typo Brandon Williams
2017-03-17 17:22     ` [PATCH v3 2/5] setup: allow for prefix to be passed to git commands Brandon Williams
2017-03-17 19:07       ` Stefan Beller
2017-03-17 19:08         ` Brandon Williams
2017-03-17 19:10           ` Stefan Beller
2017-03-17 19:17             ` Brandon Williams
2017-03-17 19:17         ` Junio C Hamano
2017-03-17 19:21           ` Brandon Williams
2017-03-17 20:30             ` Junio C Hamano
2017-03-17 21:00               ` Brandon Williams
2017-03-17 21:25                 ` Junio C Hamano
2017-03-20 22:34                   ` Brandon Williams
2017-03-21 16:56                     ` Junio C Hamano
2017-03-28 23:58                     ` Stefan Beller
2017-03-17 17:22     ` [PATCH v3 3/5] grep: fix bug when recursing with relative pathspec Brandon Williams
2017-03-21 11:47       ` Duy Nguyen
2017-03-21 17:56         ` Junio C Hamano
2017-03-22 21:46         ` Brandon Williams
2017-03-17 17:22     ` [PATCH v3 4/5] ls-files: fix typo in variable name Brandon Williams
2017-03-17 17:22     ` [PATCH v3 5/5] ls-files: fix bug when recursing with relative pathspec 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

  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='CACsJy8Df6hhTzx5BNx385T4cuCg5w3nvOioXB=q+NCoW9kA6_w@mail.gmail.com' \
    --to=pclouds@gmail.com \
    --cc=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=sbeller@google.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).