threads / patch / 27000

patchpathspec: rename per-item field has_wildcard to use_wildcard

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

## tl;dr

11 messages between Apr 5, 2011 and Apr 8, 2011. Diffs are folded; open one to read it.

replies: 10people: 3as markdown or json

Junio C Hamano· Apr 5, 2011, 22:10 UTC · lore

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(-)
Show changes to 5 files +9 −8

builtin/ls-files.c, builtin/ls-tree.c, cache.h, dir.c, tree-walk.c

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
Nguyen Thai Ngoc Duy· Apr 6, 2011, 15:54 UTC · re: Junio C Hamano · lore

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

2011/4/6 Junio C Hamano <gitster@pobox.com>:
Show 11 quoted lines
>  * 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
Junio C Hamano· Apr 6, 2011, 17:13 UTC · re: Nguyen Thai Ngoc Duy · lore

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

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
Show 7 quoted lines
> 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.
Junio C Hamano· Apr 6, 2011, 19:52 UTC · re: Junio C Hamano · lore

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

Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> 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(-)
Show changes to setup.c +99 −2
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;
Michael J Gruber· Apr 7, 2011, 11:09 UTC · re: Junio C Hamano · lore

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

Junio C Hamano venit, vidit, dixit 06.04.2011 19:13:
Show 21 quoted lines
> 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 ;)
Show 30 quoted lines
> 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.

Show 8 quoted lines
> 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
Nguyen Thai Ngoc Duy· Apr 7, 2011, 13:00 UTC · re: Michael J Gruber · lore

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

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 :)
Show 14 quoted lines
>>  (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.

Show 6 quoted lines
> 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
Junio C Hamano· Apr 7, 2011, 19:44 UTC · re: Michael J Gruber · lore

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

Michael J Gruber <git@drmicha.warpmail.net> writes:
Show 14 quoted lines
> 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.

Show 27 quoted lines
>>  (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(-)
Show changes to setup.c +3 −0
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)
Junio C Hamano· Apr 7, 2011, 19:47 UTC · re: Junio C Hamano · lore

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

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.
Michael J Gruber· Apr 8, 2011, 08:29 UTC · re: Junio C Hamano · lore

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

Junio C Hamano venit, vidit, dixit 07.04.2011 21:47:
Show 11 quoted lines
> 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
Junio C Hamano· Apr 8, 2011, 19:40 UTC · re: Michael J Gruber · lore

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

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.

Nguyen Thai Ngoc Duy· Apr 7, 2011, 12:51 UTC · re: Junio C Hamano · lore

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

On Thu, Apr 7, 2011 at 12:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 19 quoted lines
> 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?
Show 10 quoted lines
>  (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.

Show 7 quoted lines
> 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

← back to recent threads