Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > On 01/08/2025 16:49, Phillip Wood wrote: >> On 01/08/2025 15:43, Junio C Hamano wrote: >>> Phillip Wood <phillip.wood123@xxxxxxxxx> writes: >>> >>> What does a double-asterisk currently do in these patterns? >> refs/heads/m** seems to behave like refs/heads/m*. I'm a bit >> surprised by that as for-each-ref seems to set WM_PATHNAME and I >> thought that our wildmatch code used '**' to match any character in >> that case. > > I'd forgotten the rules for '**' - it must come after a slash and be > followed by a slash if it is not at the end of a pattern otherwise it > is silently converted to '*'. I wish our wildmatch code at least > warned when it did that. So one can query all the branches beginning > with "m" by passing > > 'refs/heads/m*' 'refs/heads/m*/**' > > which isn't as convenient as it could be but it is possible. As long as the rules are consistent and understandable (once you understand it, that is), then I am perfectly fine. And "** is written as /**/ (but you can omit slashes at either ends)" I find acceptable. >>> - "refs/heads/m*" matches all local branches whose name starts with >>> 'm' like 'morning', but not the ones inside subhierarchies that >>> start with 'm' like 'mid/night'. >>> >>> - "refs/heads/m**" matches all local branches whose name starts >>> with 'm' and in the ones inside subhierarchies that start with >>> 'm'. >> That sounds like a good idea > > Now I'm not so sure. As long as the existing rule is serviceable (and you seem to have found that it is), we do not need to make such a change. Thanks for thinking it through.