All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brandon Williams <bmwill@google.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: git@vger.kernel.org, "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Subject: Re: [PATCH] pathspec: always honor `PATHSPEC_PREFIX_ORIGIN` flag
Date: Mon, 3 Apr 2017 09:26:48 -0700	[thread overview]
Message-ID: <20170403162648.GA166794@google.com> (raw)
In-Reply-To: <1556910880cfce391bdca2d8f0cbcb8c71371691.1491206540.git.ps@pks.im>

On 04/03, Patrick Steinhardt wrote:
> Previous to commit 5d8f084a5 (pathspec: simpler logic to prefix original
> pathspec elements, 2017-01-04), we were always using the computed
> `match` variable to perform pathspec matching whenever
> `PATHSPEC_PREFIX_ORIGIN` is set. This is for example useful when passing
> the parsed pathspecs to other commands, as the computed `match` may
> contain a pathspec relative to the repository root. The commit changed
> this logic to only do so when we do have an actual prefix and when
> literal pathspecs are deactivated.
> 
> But this change may actually break some commands which expect passed
> pathspecs to be relative to the repository root. One such case is `git
> add --patch`, which now fails when using relative paths from a
> subdirectory. For example if executing "git add -p ../foo.c" in a
> subdirectory, the `git-add--interactive` command will directly pass
> "../foo.c" to `git-ls-files`. As ls-files is executed at the
> repository's root, the command will notice that "../foo.c" is outside
> the repository and fail.
> 
> Fix the issue by again using the computed `match` variable whenever
> `PATHSPEC_PREFIX_ORIGIN` is set. This restores behavior previous to
> 5d8f084a5 and fixes interactive add.
> 
> Signed-off-by: Patrick Steinhardt <ps@pks.im>
> ---
>  pathspec.c                 |  6 +++---
>  t/t3701-add-interactive.sh | 20 ++++++++++++++++++++
>  2 files changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/pathspec.c b/pathspec.c
> index 303efda83..3193e45a6 100644
> --- a/pathspec.c
> +++ b/pathspec.c
> @@ -504,12 +504,12 @@ static void init_pathspec_item(struct pathspec_item *item, unsigned flags,
>  	 * Prefix the pathspec (keep all magic) and assign to
>  	 * original. Useful for passing to another command.
>  	 */
> -	if ((flags & PATHSPEC_PREFIX_ORIGIN) &&
> -	    prefixlen && !get_literal_global()) {
> +	if (flags & PATHSPEC_PREFIX_ORIGIN) {
>  		struct strbuf sb = STRBUF_INIT;
>  
>  		/* Preserve the actual prefix length of each pattern */
> -		prefix_magic(&sb, prefixlen, element_magic);
> +		if (prefixlen && !get_literal_global())
> +			prefix_magic(&sb, prefixlen, element_magic);
>  
>  		strbuf_addstr(&sb, match);
>  		item->original = strbuf_detach(&sb, NULL);

Would it just make sense to drop the requirement that prefixlen be
non-zero?  My problem with this change currently is the ability to get
an original string with is empty (ie "\0") which would cause git to
throw some warnings about not allowing empty strings as pathspecs if
they were then passed on to other processes.

> diff --git a/t/t3701-add-interactive.sh b/t/t3701-add-interactive.sh
> index f9528fa00..640088dd6 100755
> --- a/t/t3701-add-interactive.sh
> +++ b/t/t3701-add-interactive.sh
> @@ -436,6 +436,26 @@ test_expect_success 'add -p handles globs' '
>  	test_cmp expect actual
>  '
>  
> +test_expect_success 'add -p handles relative paths' '
> +	git reset --hard &&
> +
> +	echo base >root.c &&
> +	git add "*.c" &&
> +	git commit -m base &&
> +
> +	echo change >root.c &&
> +	mkdir -p subdir &&
> +	git -C subdir add -p "../root.c" <<-\EOF &&
> +	y
> +	EOF
> +
> +	cat >expect <<-\EOF &&
> +	root.c
> +	EOF
> +	git diff --cached --name-only >actual &&
> +	test_cmp expect actual
> +'
> +
>  test_expect_success 'add -p does not expand argument lists' '
>  	git reset --hard &&
>  
> -- 
> 2.12.2
> 

-- 
Brandon Williams

  reply	other threads:[~2017-04-03 16:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-03  8:03 [PATCH] pathspec: always honor `PATHSPEC_PREFIX_ORIGIN` flag Patrick Steinhardt
2017-04-03 16:26 ` Brandon Williams [this message]
2017-04-04  9:17   ` Patrick Steinhardt
2017-04-05 13:40   ` Duy Nguyen

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=20170403162648.GA166794@google.com \
    --to=bmwill@google.com \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=ps@pks.im \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.