git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH v3 01/10] wildmatch: fix "**" special case

From
Duy Nguyen <pclouds@gmail.com>
Date
Jan 23, 2013, 01:04 UTC
Message-ID
<CACsJy8DiVy7tcG_t2JENKoPSFWV24Tneh4q=upPPJML4VESMag@mail.gmail.com>
In-Reply-To
<7v1udcn84w.fsf@alter.siamese.dyndns.org>
On Wed, Jan 23, 2013 at 5:51 AM, Junio C Hamano <gitster@pobox.com> wrote:
Show 8 quoted lines
> Junio C Hamano <gitster@pobox.com> writes:
>
>> We obviously do not want to set FNM_PATHNAME when we are not
>> substituting fnmatch() with wildmatch(), but I wonder if it may make
>> sense to unconditionally use WM_PATHNAME semantics when we build the
>> system with USE_WILDMATCH and calling wildmatch() in this codepath.
>> Users can always use "*/**/*" in place of "*" in their patterns
>> where they want to ignore directory boundaries.

If we do that, we need to do the same in tree_entry_interesting(). In other words, pathspec learns the new glob syntax. It's fine for an experimental flag like USE_WILDMATCH. But after fnmatch is replaced by wildmatch unconditionally (thus USE_WILDMATCH becomes obsolete), then what? Should people who expects new syntax with USE_WILDMATCH continue to have new syntax? How does a user know which syntax may be used in his friend's "git" binary?

On a related subject, I've been meaning to write a mail about the other use of patterns in git (e.g. in git-branch, git-tag, git-apply...) but never got around to. Some use without FNM_PATHNAME, some do and the document does not go into details about the differences. We might want to unify the syntax there too. It'll probably break backward compatibility so we can do the same when we switch pathspec syntax.

Show 5 quoted lines
> Another possibility, which _might_ make more practical sense, is to
> update dowild() so that any pattern that has (^|/)**(/|$) in it
> implicitly turns the WM_PATHNAME flag on.  There is no reason for
> the user to feed it a double-asterisk unless it is an attempt to
> defeat some directory boundaries,

They may also put "**" by mistake (or realize they just put "**" but too lazy to remove one asterisk).

> so we already know that the user
> expects WM_PATHNAME behaviour at that point.  Otherwise, the user
> would have simply said '*' instead, wouldn't he?

The only problem I see is, without the version string, there's no way to know if "**" is supported. Old git versions will happily take "**" and interpret as "*". When you advise someone to use "**" you might need to add "check if you have this version of git". This problem does not exist with pathspec magic like :(glob)

> I said "_might_" because it sounds a bit too magical to my taste.
> I dunno.
-- 
Duy
Previous: Junio C HamanoNext: Junio C Hamano
Message 5 of 19 in “fnmatch replacement”
  1. 00/10 fnmatch replacementNguyễn Thái Ngọc Duy, Jan 1, 2013
  2. 01/10 wildmatch: fix "**" special caseNguyễn Thái Ngọc Duy, Jan 1, 2013
  3. Junio C HamanoJan 22, 2013
  4. Junio C HamanoJan 22, 2013
  5. Duy NguyenJan 23, 2013
  6. Junio C HamanoJan 24, 2013
  7. Duy NguyenJan 24, 2013
  8. Junio C HamanoJan 24, 2013
  9. Duy NguyenJan 25, 2013
  10. Junio C HamanoJan 25, 2013
  11. 02/10 compat/fnmatch: respect NO_FNMATCH* even on glibcNguyễn Thái Ngọc Duy, Jan 1, 2013
  12. 03/10 wildmatch: replace variable 'special' with better named onesNguyễn Thái Ngọc Duy, Jan 1, 2013
  13. 04/10 wildmatch: rename constants and update prototypeNguyễn Thái Ngọc Duy, Jan 1, 2013
  14. 05/10 wildmatch: make dowild() take arbitrary flagsNguyễn Thái Ngọc Duy, Jan 1, 2013
  15. 06/10 wildmatch: support "no FNM_PATHNAME" modeNguyễn Thái Ngọc Duy, Jan 1, 2013
  16. 07/10 test-wildmatch: add "perf" command to compare wildmatch and fnmatchNguyễn Thái Ngọc Duy, Jan 1, 2013
  17. 08/10 wildmatch: make a special case for "*/" with FNM_PATHNAMENguyễn Thái Ngọc Duy, Jan 1, 2013
  18. 09/10 wildmatch: advance faster in <asterisk> + <literal> patternsNguyễn Thái Ngọc Duy, Jan 1, 2013
  19. 10/10 Makefile: add USE_WILDMATCH to use wildmatch as fnmatchNguyễn Thái Ngọc Duy, Jan 1, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.