From: Brandon Williams <bmwill@google.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Emily Xie <emilyxxie@gmail.com>
Subject: Re: "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths"
Date: Tue, 6 Dec 2016 10:04:00 -0800 [thread overview]
Message-ID: <20161206180400.GA103573@google.com> (raw)
In-Reply-To: <xmqqtwaobni5.fsf@gitster.mtv.corp.google.com>
On 11/30, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> forgot to Cc: the author of the
> most relevant change to the issue, d426430e6e ("pathspec: warn on
> empty strings as pathspec", 2016-06-22).
>
> > Kevin Daudt <me@ikke.info> writes:
> >
> >> On Wed, Nov 30, 2016 at 12:31:49PM -0800, Peter Urda wrote:
> >>> After upgrading to version 2.11.0 I am getting a warning about empty
> >>> strings as pathspecs while using 'patch'
> >>>
> >>> - Ran 'git add -p .' from the root of my git repository.
> >>>
> >>> - I was able to normally stage my changes, but was presented with a
> >>> "warning: empty strings as pathspecs will be made invalid in upcoming
> >>> releases. please use . instead if you meant to match all paths"
> >>> message.
> >>>
> >>> - I expected no warning message since I included a "." with my original command.
> >>>
> >>> I believe that I should not be seeing this warning message as I
> >>> included the requested "." pathspec.
> >
> > Yes, this seems to be caused by pathspec.c::prefix_pathspec()
> > overwriting the original pathspec "." into "". The callchain
> > looks like this:
> >
> > builtin/add.c::interactive_add()
> > -> parse_pathspec()
> > passes argv[] that has "." to the caller,
> > receives pathspec whose pathspec->items[].original
> > is supposed to point at the unmolested original,
> > but prefix_pathspec() munges "." into ""
> > -> run_add_interactive()
> > which runs "git add--interactive" with
> > pathspec->items[].original as pathspecs
> >
> >
> > Perhaps this would work it around, but there should be a better way
> > to fix it (like, making sure that what we call "original" indeed
> > stays "original").
> >
> > builtin/add.c | 13 +++++++++++--
> > 1 file changed, 11 insertions(+), 2 deletions(-)
> >
> > diff --git a/builtin/add.c b/builtin/add.c
> > index e8fb80b36e..137097192d 100644
> > --- a/builtin/add.c
> > +++ b/builtin/add.c
> > @@ -167,9 +167,18 @@ int run_add_interactive(const char *revision, const char *patch_mode,
> > if (revision)
> > argv_array_push(&argv, revision);
> > argv_array_push(&argv, "--");
> > - for (i = 0; i < pathspec->nr; i++)
> > + for (i = 0; i < pathspec->nr; i++) {
> > /* pass original pathspec, to be re-parsed */
> > + if (!*pathspec->items[i].original) {
> > + /*
> > + * work around a misfeature in parse_pathspecs()
> > + * that munges "." into "".
> > + */
> > + argv_array_push(&argv, ".");
> > + continue;
> > + }
> > argv_array_push(&argv, pathspec->items[i].original);
> > + }
> >
> > status = run_command_v_opt(argv.argv, RUN_GIT_CMD);
> > argv_array_clear(&argv);
> > @@ -180,7 +189,7 @@ int interactive_add(int argc, const char **argv, const char *prefix, int patch)
> > {
> > struct pathspec pathspec;
> >
> > - parse_pathspec(&pathspec, 0,
> > + parse_pathspec(&pathspec, 0,
> > PATHSPEC_PREFER_FULL |
> > PATHSPEC_SYMLINK_LEADING_PATH |
> > PATHSPEC_PREFIX_ORIGIN,
I've been doing a bit of work trying to clean up the pathspec
initialization code and I believe this can be fixed without
having to add in this work around. The code which does the munging is
always trying to prefix the pathspec regardless if there is a prefix or
not. If instead its changed to only try and prefix the original if
there is indeed a prefix, then it should fix the munging.
I'll try to get the series I'm working on out in the next day.
--
Brandon Williams
next prev parent reply other threads:[~2016-12-06 18:04 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-30 20:31 "git add -p ." raises an unexpected "warning: empty strings as pathspecs will be made invalid in upcoming releases. please use . instead if you meant to match all paths" Peter Urda
2016-11-30 21:11 ` Kevin Daudt
2016-11-30 22:04 ` Junio C Hamano
2016-11-30 22:40 ` Junio C Hamano
2016-12-06 18:04 ` Brandon Williams [this message]
2016-12-06 21:21 ` Junio C Hamano
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=20161206180400.GA103573@google.com \
--to=bmwill@google.com \
--cc=emilyxxie@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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 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.