All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Stavros Ntentos <stdedos@gmail.com>,
	bagasdotme@gmail.com, git@vger.kernel.org, stdedos+git@gmail.com
Subject: Re: [RFC PATCH v1 1/2] pathspec: warn: long and short forms are incompatible
Date: Sat, 27 Mar 2021 11:36:20 -0700	[thread overview]
Message-ID: <xmqqa6qoqw9n.fsf@gitster.g> (raw)
In-Reply-To: <YF792/TkS3Ssw9NS@coredump.intra.peff.net> (Jeff King's message of "Sat, 27 Mar 2021 05:41:47 -0400")

Jeff King <peff@peff.net> writes:

> It also feels like any checks like this should be relying on the
> existing pathspec-magic parser a bit more. I don't know the pathspec
> code that well, but surely at some point it has a notion of which parts
> are magic flags (e.g., after parse_element_magic in init_pathspec_item).

Absolutely.  parse_element_magic() decides, by looking at the
character after the initial ':', the we are looking at the longhand
form when magic sequence is introduced by ":(".

Otherwise, : must be followed by shorthand form, where the only
usable ones are '/' (synonym for top), '!' and '^' (synonym for
exclude), and ':' (end of short-form marker), but most importantly,
'(' will *never* be a valid shorthand form (because it is not part
of the GIT_PATHSPEC_MAGIC class of bytes).

So, presumably, inside parse_short_magic(), you could detect '('
and complain it as an attempt to switch to longform.

Here is to illustrate where to hook the check.  With this, I can get
something like this:

    $ git show -s --oneline -- ':!/(foobar)frotz' ':/(bar)nitfol' .
    warning: :!/: cannot mix shortform magic with longform like (exclude)
    warning: :/: cannot mix shortform magic with longform like (exclude)
    84d06cdc06 Sync with v2.31.1

Note that this illustration does not show the best warning message.
To improve it to a bit more useful level, I think two things need to
happen on top.

 * Use advice to allow users sequelch.

 * Show a few letters after '(' (but pay attention to the end of the
   string, which ends with either '\0' or ':'), and lose the
   substring "like (exclude)" from the message.

That would have given

    hint: ":!/(foo...": cannot mix shortform and longform magic

for the above example.

I initially thought it might make it even better if we looked ahead
of what comes after '(', took the substring before ',' or ')', and
looked up pathspec_magic[] array, BUT I do not think it is a good
idea.  It would be confusing if we do not give the same advice to
":!(literol)" when the user does get one for ":!(literal)".  So the
above "two things need to happen" list deliberately excludes an
"improvement" doing so.


 pathspec.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git i/pathspec.c w/pathspec.c
index 18b3be362a..cd343d5b54 100644
--- i/pathspec.c
+++ w/pathspec.c
@@ -336,6 +336,9 @@ static const char *parse_long_magic(unsigned *magic, int *prefix_len,
 	return pos;
 }
 
+static const char mixed_pathspec_magic[] =
+	N_("%.*s: cannot mix shortform magic with longform like (exclude)");
+
 /*
  * Parse the pathspec element looking for short magic
  *
@@ -356,6 +359,16 @@ static const char *parse_short_magic(unsigned *magic, const char *elem)
 			continue;
 		}
 
+		if (ch == '(') {
+			/*
+			 * a possible common mistake: once you started
+			 * a shortform you cannot add (longform), e.g.
+			 * ":!(top)"
+			 */
+			warning(_(mixed_pathspec_magic),
+				(int)(pos-elem), elem);
+		}
+
 		if (!is_pathspec_magic(ch))
 			break;
 


  reply	other threads:[~2021-03-27 18:37 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-26 20:44 Pathspec does not accept / does not warn for specific pathspecs Σταύρος Ντέντος
2021-02-26 23:27 ` Junio C Hamano
2021-03-25 10:22   ` [PATCH v1 0/1] pathspec: warn for a no-glob entry that contains `**` Σταύρος Ντέντος
2021-03-25 10:22     ` [PATCH v1 1/1] " Σταύρος Ντέντος
2021-03-25 11:00       ` Bagas Sanjaya
2021-03-25 11:04       ` Bagas Sanjaya
2021-03-25 16:09         ` Stavros Ntentos
2021-03-25 20:09           ` Junio C Hamano
2021-03-25 23:36   ` [PATCH v2 0/1] " Σταύρος Ντέντος
2021-03-25 23:36   ` [PATCH v2 1/1] " Σταύρος Ντέντος
2021-03-26  0:41     ` Junio C Hamano
2021-03-26  1:32       ` Eric Sunshine
2021-03-26  3:02         ` Junio C Hamano
2021-03-26  5:13           ` Jeff King
2021-03-26 15:43             ` Stavros Ntentos
2021-03-26 15:48     ` [PATCH v3 1/2] " Stavros Ntentos
2021-03-26 15:48       ` [PATCH v3 2/2] pathspec: convert no-glob warn to advice Stavros Ntentos
2021-03-26  2:40   ` [RFC PATCH v1 0/1] pathspec: warn: long and short forms are incompatible Σταύρος Ντέντος
2021-03-26  2:40     ` [RFC PATCH v1 1/2] " Σταύρος Ντέντος
2021-03-26  5:28       ` Jeff King
2021-03-26 16:16         ` Stavros Ntentos
2021-03-27  9:41           ` Jeff King
2021-03-27 18:36             ` Junio C Hamano [this message]
2021-03-28 15:44               ` Stavros Ntentos
2021-03-26  2:40     ` [RFC PATCH v1 2/2] fixup! " Σταύρος Ντέντος
2021-03-26  8:14       ` Bagas Sanjaya
2021-03-26 15:55         ` Stavros Ntentos
2021-03-28 15:26       ` [RFC PATCH v1 3/3] squash! " Stavros Ntentos
2021-03-26  2:44   ` [RFC PATCH v1 0/1] " Σταύρος Ντέντος
2021-03-26  2:44     ` [RFC PATCH v1] " Σταύρος Ντέντος
2021-04-03 12:26     ` [PATCH v3] pathspec: advice: " Stavros Ntentos
2021-04-04  7:19       ` Junio C Hamano
2021-04-11 15:07         ` Σταύρος Ντέντος
2021-04-11 19:10           ` Junio C Hamano
2021-04-11 20:53             ` Σταύρος Ντέντος
2021-03-28 15:45   ` [PATCH v2] " Stavros Ntentos
2021-03-28 19:12     ` Junio C Hamano
2021-03-30 17:37       ` Junio C Hamano
2021-03-30 19:05       ` Stavros Ntentos
2021-03-30 19:17         ` Stavros Ntentos
2021-03-30 20:36         ` Junio C Hamano
2021-04-03 12:48   ` [PATCH v3] " Stavros Ntentos
2021-04-03 12:51   ` [PATCH v4] " Stavros Ntentos

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=xmqqa6qoqw9n.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=bagasdotme@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=stdedos+git@gmail.com \
    --cc=stdedos@gmail.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.