[PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Junio C Hamano]

As the point of the last change is to allow use of strings as
literals no matter what characters are in them, "has_wildcard"
does not match what we use this field for anymore.

It is used to decide if the wildcard matching should be used, so
rename it to match the usage better.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * I was looking at the codepaths that would need to be touched in order
   to properly support the "magic pathspec" we have been discussing, and
   am leaning to conclude that all the users of get_pathspec() need to be
   rewritten to throw the remainder of argv[] at a function that fills a
   struct pathspec (in other words, a combination of get_pathspec() and
   init_pathspec()).  Michael's "alternative approach to grep --full-tree"
   was operating at the get_pathspec() level, but that function is an
   interface to return an array of plain-vanilla strings only, and there
   is no place to hook richer per-item information on the elements.  We
   would need "struct pathspec" in the function where we parse the argv[]
   and combine its elements with prefix.

   In any case, pathspec.has_wildcard vs pathspec.item[i].has_wildcard was
   difficult to grep and find patterns, and this is an obvious fix to that
   problem, independent from the above observation.

 builtin/ls-files.c |    2 +-
 builtin/ls-tree.c  |    3 ++-
 cache.h            |    2 +-
 dir.c              |    6 +++---
 tree-walk.c        |    4 ++--
 5 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/builtin/ls-files.c b/builtin/ls-files.c
index 199af46..1570123 100644
--- a/builtin/ls-files.c
+++ b/builtin/ls-files.c
@@ -361,7 +361,7 @@ void overlay_tree_on_cache(const char *tree_name, const char *prefix)
 		matchbuf[0] = prefix;
 		matchbuf[1] = NULL;
 		init_pathspec(&pathspec, matchbuf);
-		pathspec.items[0].has_wildcard = 0;
+		pathspec.items[0].use_wildcard = 0;
 	} else
 		init_pathspec(&pathspec, NULL);
 	if (read_tree(tree, 1, &pathspec))
diff --git a/builtin/ls-tree.c b/builtin/ls-tree.c
index 4290723..f08c5b0 100644
--- a/builtin/ls-tree.c
+++ b/builtin/ls-tree.c
@@ -168,7 +168,8 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
 
 	init_pathspec(&pathspec, get_pathspec(prefix, argv + 1));
 	for (i = 0; i < pathspec.nr; i++)
-		pathspec.items[i].has_wildcard = 0;
+		pathspec.items[i].use_wildcard = 0;
+	pathspec.has_wildcard = 0;
 	tree = parse_tree_indirect(sha1);
 	if (!tree)
 		die("not a tree object");
diff --git a/cache.h b/cache.h
index edd5b5a..43d719d 100644
--- a/cache.h
+++ b/cache.h
@@ -509,7 +509,7 @@ struct pathspec {
 	struct pathspec_item {
 		const char *match;
 		int len;
-		unsigned int has_wildcard:1;
+		unsigned int use_wildcard:1;
 	} *items;
 };
 
diff --git a/dir.c b/dir.c
index 168dad6..91f1502 100644
--- a/dir.c
+++ b/dir.c
@@ -230,7 +230,7 @@ static int match_pathspec_item(const struct pathspec_item *item, int prefix,
 			return MATCHED_RECURSIVELY;
 	}
 
-	if (item->has_wildcard && !fnmatch(match, name, 0))
+	if (item->use_wildcard && !fnmatch(match, name, 0))
 		return MATCHED_FNMATCH;
 
 	return 0;
@@ -1286,8 +1286,8 @@ int init_pathspec(struct pathspec *pathspec, const char **paths)
 
 		item->match = path;
 		item->len = strlen(path);
-		item->has_wildcard = !no_wildcard(path);
-		if (item->has_wildcard)
+		item->use_wildcard = !no_wildcard(path);
+		if (item->use_wildcard)
 			pathspec->has_wildcard = 1;
 	}
 
diff --git a/tree-walk.c b/tree-walk.c
index 322becc..33f749e 100644
--- a/tree-walk.c
+++ b/tree-walk.c
@@ -598,7 +598,7 @@ int tree_entry_interesting(const struct name_entry *entry,
 					&never_interesting))
 				return 1;
 
-			if (ps->items[i].has_wildcard) {
+			if (ps->items[i].use_wildcard) {
 				if (!fnmatch(match + baselen, entry->path, 0))
 					return 1;
 
@@ -614,7 +614,7 @@ int tree_entry_interesting(const struct name_entry *entry,
 		}
 
 match_wildcards:
-		if (!ps->items[i].has_wildcard)
+		if (!ps->items[i].use_wildcard)
 			continue;
 
 		/*
-- 
1.7.5.rc0.131.gfa38c

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Nguyen Thai Ngoc Duy]

2011/4/6 Junio C Hamano <gitster@pobox.com>:
>  * I was looking at the codepaths that would need to be touched in order
>   to properly support the "magic pathspec" we have been discussing, and
>   am leaning to conclude that all the users of get_pathspec() need to be
>   rewritten to throw the remainder of argv[] at a function that fills a
>   struct pathspec (in other words, a combination of get_pathspec() and
>   init_pathspec()).  Michael's "alternative approach to grep --full-tree"
>   was operating at the get_pathspec() level, but that function is an
>   interface to return an array of plain-vanilla strings only, and there
>   is no place to hook richer per-item information on the elements.  We
>   would need "struct pathspec" in the function where we parse the argv[]
>   and combine its elements with prefix.

I have started working on the conversion, but it may take a while
because in many places pathspec is still assumed a prefix (and handled
separately, which is not good for negative pathspec). Fundamental
support for magic pathspec and "top dir" notation probably do not need
get_pathspec() converted to struct pathspec.
-- 
Duy

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

> 2011/4/6 Junio C Hamano <gitster@pobox.com>:
>
> I have started working on the conversion, but it may take a while
> because in many places pathspec is still assumed a prefix (and handled
> separately, which is not good for negative pathspec). Fundamental
> support for magic pathspec and "top dir" notation probably do not need
> get_pathspec() converted to struct pathspec.

I think you meant to say "If we only want to have 'top dir' magic,
fundamental support and get_pathspec() conversion are unnecessary", and I
agree 100%.

I am actually tempted to add Michael's hack to get_pathspec() only to
support the "from the top" (and error out with any other magic---as the
approach without a proper restructuring will not work with anything but
that particular magic), to get the "add -u" topic going, and let you (or
other people who are interested in the pathspec rationalization) later fix
it up just a small part of existing issues.

The extensible syntax I have in mind (we only parse in get_pathspec() in
such a tentative version but anything other than the :/ will error out) is
to use:

 (1) Colon, a run of selected non-alpha (i.e. magic signature), an
     optional colon to terminate the magic signature, followed by the
     path, e.g.

     - ":/hello.c" is a path from the top.

     - ":!/hello.c" is path from the top but no globbing.

     - ":/!hello.c" is the same as above.

     - ":/::hello.c" is ":hello.c" from the top, the second colon
       terminates the magic signature and allows the funny file with a
       leading colon to be named.

     - "::hello.c" does not have any magic, is the same as "hello.c".

 (2) Colon, open parenthesis, a comma separated list of words to name
     magic, close parenthesis, followed by the path, e.g. these are the
     long-hand counterparts to the examples in (1)

     - ":(top)hello.c"
     - ":(top,noglob)hello.c"
     - ":(noglob,top)hello.c"
     - ":(noglob,top):hello.c"
     - ":()hello.c"

At this point, I am not interested in building the repertoire of magic
yet, but would want to nail a syntax that is

 - concise in common cases (e.g. "from the top, not a funny name" is ':/'
   followed by the name);
 - is extensible in the future; and
 - easy to parse and error out on magic we do not understand.

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> I am actually tempted to add Michael's hack to get_pathspec() only to
> support the "from the top" (and error out with any other magic---as the
> approach without a proper restructuring will not work with anything but
> that particular magic), to get the "add -u" topic going, and let you (or
> other people who are interested in the pathspec rationalization) later fix
> it up just a small part of existing issues.

Just a heads-up; it would look like this (no docs, tests, nor "add -u"
message updates yet).  The entries other than "top" should not be in the
final version but I just wanted to make sure that the extensibility would
look sane.


 setup.c |  101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
 1 files changed, 99 insertions(+), 2 deletions(-)

diff --git a/setup.c b/setup.c
index 03cd84f..704a930 100644
--- a/setup.c
+++ b/setup.c
@@ -126,6 +126,104 @@ void verify_non_filename(const char *prefix, const char *arg)
 	    "Use '--' to separate filenames from revisions", arg);
 }
 
+/*
+ * Magic pathspec
+ *
+ * NEEDSWORK: These need to be moved to dir.h or even to a new
+ * pathspec.h when we restructure get_pathspec() users to use the
+ * "struct pathspec" interface.
+ */
+#define PATHSPEC_FROMTOP    (1<<0)
+#define PATHSPEC_NOGLOB     (1<<1)
+#define PATHSPEC_ICASE      (1<<2)
+#define PATHSPEC_RECURSIVE  (1<<3)
+#define PATHSPEC_REGEXP     (1<<4)
+
+struct pathspec_magic {
+	unsigned bit;
+	char mnemonic; /* cannot be ':'! */
+	const char *name;
+} pathspec_magic[] = {
+	{ PATHSPEC_FROMTOP, '/', "top" },
+	{ PATHSPEC_NOGLOB, '!', "noglob" },
+	{ PATHSPEC_ICASE, '\0', "icase" },
+	{ PATHSPEC_RECURSIVE, '*', "recursive" },
+	{ PATHSPEC_REGEXP, '\0', "regexp" },
+};
+
+/*
+ * Take an element of a pathspec and check for magic signatures.
+ * Append the result to the prefix.
+ *
+ * For now, we only parse the syntax and throw out anything other than
+ * "top" magic.
+ *
+ * NEEDSWORK: This needs to be rewritten when we start migrating
+ * get_pathspec() users to use the "struct pathspec" interface.  For
+ * example, a pathspec element may be marked as case-insensitive, but
+ * the prefix part must always match literally, and a single stupid
+ * string cannot express such a case.
+ */
+const char *prefix_pathspec(const char *prefix, int prefixlen, const char *elt)
+{
+	unsigned magic = 0;
+	const char *copyfrom = elt;
+	int i;
+
+	if (elt[0] != ':') {
+		; /* nothing to do */
+	} else if (elt[1] == '(') {
+		/* longhand */
+		const char *nextat;
+		for (copyfrom = elt + 2;
+		     *copyfrom && *copyfrom != ')';
+		     copyfrom = nextat) {
+			size_t len = strcspn(copyfrom, ",)");
+			if (copyfrom[len] == ')')
+				nextat = copyfrom + len;
+			else
+				nextat = copyfrom + len + 1;
+			if (!len)
+				continue;
+			for (i = 0; i < ARRAY_SIZE(pathspec_magic); i++)
+				if (strlen(pathspec_magic[i].name) == len &&
+				    !strncmp(pathspec_magic[i].name, copyfrom, len)) {
+					magic |= pathspec_magic[i].bit;
+					break;
+				}
+			if (ARRAY_SIZE(pathspec_magic) <= i)
+				die("Invalid pathspec magic '%.*s' in '%s'",
+				    (int) len, copyfrom, elt);
+		}
+		if (*copyfrom == ')')
+			copyfrom++;
+	} else {
+		/* shorthand */
+		for (copyfrom = elt + 1;
+		     *copyfrom && *copyfrom != ':';
+		     copyfrom++) {
+			char ch = *copyfrom;
+			for (i = 0; i < ARRAY_SIZE(pathspec_magic); i++)
+				if (pathspec_magic[i].mnemonic == ch) {
+					magic |= pathspec_magic[i].bit;
+					break;
+				}
+			if (ARRAY_SIZE(pathspec_magic) <= i)
+				break;
+		}
+		if (*copyfrom == ':')
+			copyfrom++;
+	}
+
+	if (magic & ~(PATHSPEC_FROMTOP))
+		die("Unsupported pathspec magic in '%s'", elt);
+
+	if (magic & PATHSPEC_FROMTOP)
+		return xstrdup(copyfrom);
+	else
+		return prefix_path(prefix, prefixlen, copyfrom);
+}
+
 const char **get_pathspec(const char *prefix, const char **pathspec)
 {
 	const char *entry = *pathspec;
@@ -147,8 +245,7 @@ const char **get_pathspec(const char *prefix, const char **pathspec)
 	dst = pathspec;
 	prefixlen = prefix ? strlen(prefix) : 0;
 	while (*src) {
-		const char *p = prefix_path(prefix, prefixlen, *src);
-		*(dst++) = p;
+		*(dst++) = prefix_pathspec(prefix, prefixlen, *src);
 		src++;
 	}
 	*dst = NULL;

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 06.04.2011 19:13:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> 
>> 2011/4/6 Junio C Hamano <gitster@pobox.com>:
>>
>> I have started working on the conversion, but it may take a while
>> because in many places pathspec is still assumed a prefix (and handled
>> separately, which is not good for negative pathspec). Fundamental
>> support for magic pathspec and "top dir" notation probably do not need
>> get_pathspec() converted to struct pathspec.
> 
> I think you meant to say "If we only want to have 'top dir' magic,
> fundamental support and get_pathspec() conversion are unnecessary", and I
> agree 100%.
> 
> I am actually tempted to add Michael's hack to get_pathspec() only to
> support the "from the top" (and error out with any other magic---as the
> approach without a proper restructuring will not work with anything but
> that particular magic), to get the "add -u" topic going, and let you (or
> other people who are interested in the pathspec rationalization) later fix
> it up just a small part of existing issues.
> 

Junio, we're in rc phase ;)

> The extensible syntax I have in mind (we only parse in get_pathspec() in
> such a tentative version but anything other than the :/ will error out) is
> to use:
> 
>  (1) Colon, a run of selected non-alpha (i.e. magic signature), an
>      optional colon to terminate the magic signature, followed by the
>      path, e.g.
> 
>      - ":/hello.c" is a path from the top.
> 
>      - ":!/hello.c" is path from the top but no globbing.
> 
>      - ":/!hello.c" is the same as above.
> 
>      - ":/::hello.c" is ":hello.c" from the top, the second colon
>        terminates the magic signature and allows the funny file with a
>        leading colon to be named.
> 
>      - "::hello.c" does not have any magic, is the same as "hello.c".
> 
>  (2) Colon, open parenthesis, a comma separated list of words to name
>      magic, close parenthesis, followed by the path, e.g. these are the
>      long-hand counterparts to the examples in (1)
> 
>      - ":(top)hello.c"
>      - ":(top,noglob)hello.c"
>      - ":(noglob,top)hello.c"
>      - ":(noglob,top):hello.c"
>      - ":()hello.c"
> 

Do we need the parentheses? I guess we need them to have the magic start
with a non-alpha, otherwise we could do with ":top,noglob:hello.c"
(which I like but breaks those with a file named ":top:hello.c").

What about these:

:/(noglob)hello.c
:(top)!hello.c

I.e. do we allow combinations?

Do we need the the second colon at all then? I.e. we can declare ":"
non-magic after seeing it once so that ":(top):hello.c" would be
":hello.c" at top.

> At this point, I am not interested in building the repertoire of magic
> yet, but would want to nail a syntax that is
> 
>  - concise in common cases (e.g. "from the top, not a funny name" is ':/'
>    followed by the name);
>  - is extensible in the future; and
>  - easy to parse and error out on magic we do not understand.
> 

- and does dot break users with files named xyz.

Spelling out xyz would already nail down the syntax quite a bit. It
seems you accept to break people with files named ":(top)hello.c" but
not those with files named ":top:hello.c". Which is OK if it's a
conscious decision, of course.

Michael

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Nguyen Thai Ngoc Duy]

On Thu, Apr 7, 2011 at 6:09 PM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Junio, we're in rc phase ;)

He was excited. It's good, we may get this feature sooner :)

>>  (2) Colon, open parenthesis, a comma separated list of words to name
>>      magic, close parenthesis, followed by the path, e.g. these are the
>>      long-hand counterparts to the examples in (1)
>>
>>      - ":(top)hello.c"
>>      - ":(top,noglob)hello.c"
>>      - ":(noglob,top)hello.c"
>>      - ":(noglob,top):hello.c"
>>      - ":()hello.c"
>>
>
> Do we need the parentheses? I guess we need them to have the magic start
> with a non-alpha, otherwise we could do with ":top,noglob:hello.c"
> (which I like but breaks those with a file named ":top:hello.c").

That has something to do with "easy to parse and catch error", I
think. At the moment ":hello/:world" is interpreted as "hello/:world".
Without parentheses, we need to look further for colon and may
accidentally misinterpret it.

> What about these:
>
> :/(noglob)hello.c
> :(top)!hello.c
>
> I.e. do we allow combinations?

I think we should. I don't like typing long pathspecs, just because
only remember mnemonic for "top" and happen to need "noglob" too.

> It seems you accept to break people with files named ":(top)hello.c" but
> not those with files named ":top:hello.c". Which is OK if it's a
> conscious decision, of course.

At least once we agree on colon being the magic introducer and general
rules, we can do these earlier in 1.7.x

 - warn people that ":hello.c" may change semantics in future
 - recommend to escape ("::hello.c" instead of ":hello.c")
-- 
Duy

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Junio C Hamano venit, vidit, dixit 06.04.2011 19:13:
> ...
>> I think you meant to say "If we only want to have 'top dir' magic,
>> fundamental support and get_pathspec() conversion are unnecessary", and I
>> agree 100%.
>> 
>> I am actually tempted to add Michael's hack to get_pathspec() only to
>> support the "from the top" (and error out with any other magic---as the
>> approach without a proper restructuring will not work with anything but
>> that particular magic), to get the "add -u" topic going, and let you (or
>> other people who are interested in the pathspec rationalization) later fix
>> it up just a small part of existing issues.
>
> Junio, we're in rc phase ;)

I know ;-).  All the patches I sent out yesterday are to be held until
1.7.5 ships.

Because I doubt that the major restructuring we discussed earlier won't be
ready within the 1.7.6 timeframe, I think it would make sense to ship the
version of "git add -u/-A" update that does not use any confvar but does
suggest the use of ':/' (it seems none of us is totally unhappy with that
notation) or '.', which I think is a far superiour solution, in 1.7.6.

That gives us more time to enhance the magic pathspec for later versions,
but still will give plenty of time to the users for "git add -u/-A"
migration planned for 1.8.0 version bump.  Hooking at the get_pathspec()
level is a compromise to make that happen, as long as we nailed the syntax
right so that we do not have to break people's fingers and scripts when we
redo the logic for the magic pathspec at the right level of the API.

>>  (1) Colon, a run of selected non-alpha (i.e. magic signature), an
>>      optional colon to terminate the magic signature, followed by the
>>      path, e.g.
>> 
>>      - ":/hello.c" is a path from the top.
>> 
>>      - ":!/hello.c" is path from the top but no globbing.
>> 
>>      - ":/!hello.c" is the same as above.
>> 
>>      - ":/::hello.c" is ":hello.c" from the top, the second colon
>>        terminates the magic signature and allows the funny file with a
>>        leading colon to be named.
>> 
>>      - "::hello.c" does not have any magic, is the same as "hello.c".
>> 
>>  (2) Colon, open parenthesis, a comma separated list of words to name
>>      magic, close parenthesis, followed by the path, e.g. these are the
>>      long-hand counterparts to the examples in (1)
>> 
>>      - ":(top)hello.c"
>>      - ":(top,noglob)hello.c"
>>      - ":(noglob,top)hello.c"
>>      - ":(noglob,top):hello.c"
>>      - ":()hello.c"
>
> Do we need the parentheses?

We bracket spelled-out names, e.g. %(refname), ^{commit}, as opposed to
not bracket a short-hand to keep them, eh, short.  Also the fact that ":("
is a very unlikely character sequence to begin a pathname will help avoid
clashing with real pathnames.  Short-form magic mnemonic consists only of
non-alphanumeric, and ":x" for any 'x' that is a non-alphanumeric is also
a very unlikely character sequence to begin a pathname.

> What about these:
>
> :/(noglob)hello.c
> :(top)!hello.c

Not interested.  It is Ok if mnemonic form is a bit complex to explain, as
long as the end result is short to type once the user understands it.  When
a long form is involved, the rule should be as simple as possible to help
people who haven't taken the time to understand the possible complex short
form parsing rules that is necessary to keep the short form short.

> Spelling out xyz would already nail down the syntax quite a bit. It
> seems you accept to break people with files named ":(top)hello.c" but
> not those with files named ":top:hello.c".

I think we actually _do_ break ":top:hello.c", which the yesterday's patch
would parse as a pattern "top:hello.c" that does not have any magic, and
you would need to quote it, i.e. "\:top:hello.c" or ":::top:hello.c", if
you mean ":top:hello.c" is the pattern, I think.

I have considered to tweak the syntax definition further to allow you to
say ":Makefile" (which would parse as a pattern "Makefile" without any
magic with yesterday's patch) and automagically add "top" magic to it,
because "top" would be the most common thing you would want to say, and
because it would make it look similar to "HEAD:Makefile" (the blob object
in HEAD tree) or ":Makefile" (the blob object in the index).  A three
liner patch is attached.

But that would mean that we are not just saying "a colon ':' followed by a
non-alphanumeric is an unlikely sequence".  We would be saying "a colon
':' is an unlikely character to begin a pathname".  I think that is going
a bit too far.  So we probably would not want to do this.

 setup.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/setup.c b/setup.c
index 820ed05..4ebedd4 100644
--- a/setup.c
+++ b/setup.c
@@ -213,6 +213,9 @@ const char *prefix_pathspec(const char *prefix, int prefixlen, const char *elt)
 		}
 		if (*copyfrom == ':')
 			copyfrom++;
+		else if (copyfrom == elt + 1)
+			/* Special case: ":Makefile" -> ":/Makefile" */
+			magic = PATHSPEC_FROMTOP;
 	}
 
 	if (magic & PATHSPEC_FROMTOP)

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Junio C Hamano]

Junio C Hamano <gitster@pobox.com> writes:

> Because I doubt that the major restructuring we discussed earlier won't be
> ready within the 1.7.6 timeframe,...

I think people involved in this thread have dealt with my bad writing long
enough and understood what I meant, but just in case, I meant to say that
I do not think restructuring would be ready to ship with 1.7.6,
in other words, s/won't/will/ is needed above.

Sorry for a noise.

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Michael J Gruber]

Junio C Hamano venit, vidit, dixit 07.04.2011 21:47:
> Junio C Hamano <gitster@pobox.com> writes:
> 
>> Because I doubt that the major restructuring we discussed earlier won't be
>> ready within the 1.7.6 timeframe,...
> 
> I think people involved in this thread have dealt with my bad writing long
> enough and understood what I meant, but just in case, I meant to say that
> I do not think restructuring would be ready to ship with 1.7.6,
> in other words, s/won't/will/ is needed above.
> 
> Sorry for a noise.

No problem, that was clear from the context. "Doubt" is such a weak form
of negation that many people miss that possible double negation. In
several languages (or even dialects) a double negation is a strong form
of negation.

The time line sounds very sane, and I'm with the parentheses. What I'm
wondering about are :foo and :foo:bar (which have no modifiers to
parse). I thought you meant to eat the ":" only in the former and not
the latter but I guess I was mistaken. Maybe we can make the ":" literal
when it can't be parsed, or make it do something (":/" as you
suggested), because swallowing it and then doing nothing seems doubly bad.

Michael

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Junio C Hamano]

Michael J Gruber <git@drmicha.warpmail.net> writes:

> Maybe we can make the ":" literal
> when it can't be parsed, or make it do something (":/" as you
> suggested), because swallowing it and then doing nothing seems doubly bad.

Another possible tweak would be to make ":" without even any "pattern"
after it to become a no-element, in order to allow the same difference
between "git log" and "git log ." to be expressed from within a
subdirectory.

The difference matters when you have commits created with --allow-empty
that are discarded by path based history simplification.

Re: [PATCH] pathspec: rename per-item field has_wildcard to use_wildcard

[Nguyen Thai Ngoc Duy]

On Thu, Apr 7, 2011 at 12:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> The extensible syntax I have in mind (we only parse in get_pathspec() in
> such a tentative version but anything other than the :/ will error out) is
> to use:
>
>  (1) Colon, a run of selected non-alpha (i.e. magic signature), an
>     optional colon to terminate the magic signature, followed by the
>     path, e.g.
>
>     - ":/hello.c" is a path from the top.
>
>     - ":!/hello.c" is path from the top but no globbing.
>
>     - ":/!hello.c" is the same as above.
>
>     - ":/::hello.c" is ":hello.c" from the top, the second colon
>       terminates the magic signature and allows the funny file with a
>       leading colon to be named.
>
>     - "::hello.c" does not have any magic, is the same as "hello.c".

What about ":hello.c", same as "hello.c"? I think we need to reserve
some more characters for future extension. The selected set of magic
in your patch misses my favourite negate magic :)

By the way, I think we should use a better term than "magic". Pathspec modifier?

>  (2) Colon, open parenthesis, a comma separated list of words to name
>     magic, close parenthesis, followed by the path, e.g. these are the
>     long-hand counterparts to the examples in (1)
>
>     - ":(top)hello.c"
>     - ":(top,noglob)hello.c"
>     - ":(noglob,top)hello.c"
>     - ":(noglob,top):hello.c"
>     - ":()hello.c"
>

Can we mix short and long magic? It seems impossible in your patch. I
don't know if that's the intention.

> At this point, I am not interested in building the repertoire of magic
> yet, but would want to nail a syntax that is
>
>  - concise in common cases (e.g. "from the top, not a funny name" is ':/'
>   followed by the name);
>  - is extensible in the future; and
>  - easy to parse and error out on magic we do not understand.
-- 
Duy