{"thread":{"id":"59605","subject":"Glob patterns w/ **; zero or more?","startedAt":"2023-04-16T18:41:01Z","lastAt":"2023-04-16T19:10:24Z","messageCount":2,"participants":["Maël Nison","Andreas Schwab"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"475494","messageId":"CANiF4iAaWB9j+Mma0-yfp6GvoQuM4k_OBAXn0keR+vCg8PQjmA@mail.gmail.com","threadId":"59605","inReplyTo":null,"subject":"Glob patterns w/ **; zero or more?","fromName":"Maël Nison","fromEmail":"nison.mael@gmail.com","sentAt":"2023-04-16T18:40:43Z","receivedAt":"2023-04-16T18:41:01Z","isPatch":false,"sender":{"key":"nison.mael@gmail.com","avatar":null},"body":"Hi,\n\nI noticed that, in a repo with a single `main.c` file, `git ls-files\n'./**/main.c'` (note the surrounding quotes, to avoid shell globbing)\nreturns no result even though `git ls-files main.c` does. It however\ncan find any `main.c` file located in a subdirectory, suggesting `**`\nis interpreted as \"one or more\" rather than \"zero or more\". Can you\nconfirm it'd be a bug? I checked in both 2.38 and 2.40.\n\nFor reference, the documentation is explicit that `**` is \"zero or\nmore\", not \"one or more\", and it matches the behaviour from other glob\nimplementations (emphasis mine):\n\n> A slash followed by two consecutive asterisks then a slash matches ***zero or\n> more directories***. For example, \"a/**/b\" matches \"a/b\", \"a/x/b\", \"a/x/y/b\" and so on.\n\nAlso quoting the bash documentation for reference:\n\n> globstar\n> If set, the pattern ‘**’ used in a filename expansion context will match all files\n> and zero or more directories and subdirectories. If the pattern is followed by\n> a ‘/’, only directories and subdirectories match.\n"},{"id":"475495","messageId":"87ttxfsl5w.fsf@igel.home","threadId":"59605","inReplyTo":"CANiF4iAaWB9j+Mma0-yfp6GvoQuM4k_OBAXn0keR+vCg8PQjmA@mail.gmail.com","subject":"Re: Glob patterns w/ **; zero or more?","fromName":"Andreas Schwab","fromEmail":"schwab@linux-m68k.org","sentAt":"2023-04-16T19:04:59Z","receivedAt":"2023-04-16T19:10:24Z","isPatch":false,"sender":{"key":"schwab@linux-m68k.org","avatar":"https://avatars.githubusercontent.com/u/2175493?v=4"},"body":"On Apr 16 2023, Maël Nison wrote:\n\n> I noticed that, in a repo with a single `main.c` file, `git ls-files\n> './**/main.c'` (note the surrounding quotes, to avoid shell globbing)\n> returns no result even though `git ls-files main.c` does. It however\n> can find any `main.c` file located in a subdirectory, suggesting `**`\n> is interpreted as \"one or more\" rather than \"zero or more\". Can you\n> confirm it'd be a bug? I checked in both 2.38 and 2.40.\n\nBy default, pathspec matching does not take \"**\" specially, making it\nequivalen to \"*\", but it can match \"/\".  Thus \"./**/main.c\" is the same\nas \"*/main.c\" (the leading \"./\" always matches) and matches paths with\nat least one \"/\" in it (thus \"*/main.c\" does not match \"main.c\").\n\nIf you use \":(glob)./**/main.c\", it uses shell glob matching, where \"**\"\nis special and \"/**/\" can match \"/\", but \"*\" does not match \"/\".\n\n-- \nAndreas Schwab, schwab@linux-m68k.org\nGPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1\n\"And now for something completely different.\"\n"}]}