From: Junio C Hamano <gitster@pobox.com>
To: Phillip Wood <phillip.wood123@gmail.com>
Cc: Meet Soni <meetsoni3017@gmail.com>,
git@vger.kernel.org, ps@pks.im, shejialuo@gmail.com,
karthik.188@gmail.com, sunshine@sunshineco.com,
John Cai <johncai86@gmail.com>
Subject: Re: [GSoC][RFC PATCH v4 3/5] builtin/refs: add list subcommand
Date: Mon, 04 Aug 2025 08:35:07 -0700 [thread overview]
Message-ID: <xmqqh5yn6qxg.fsf@gitster.g> (raw)
In-Reply-To: <61933769-1992-473e-8d0b-8cd6946e80ce@gmail.com> (Phillip Wood's message of "Mon, 4 Aug 2025 10:27:56 +0100")
Phillip Wood <phillip.wood123@gmail.com> writes:
> On 01/08/2025 16:49, Phillip Wood wrote:
>> On 01/08/2025 15:43, Junio C Hamano wrote:
>>> Phillip Wood <phillip.wood123@gmail.com> 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.
next prev parent reply other threads:[~2025-08-04 15:35 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-27 7:49 [GSoC][RFC PATCH 0/2] Add refs list subcommand Meet Soni
2025-06-27 7:49 ` [GSoC][RFC PATCH 1/2] builtin/refs: add " Meet Soni
2025-06-27 16:27 ` Jean-Noël Avila
2025-06-27 18:13 ` Junio C Hamano
2025-06-30 4:28 ` Meet Soni
2025-06-29 11:05 ` [PATCH] doc:git-for-each-ref: fix styling and typos Jean-Noël Avila
2025-06-30 15:48 ` Junio C Hamano
2025-06-30 18:55 ` Jean-Noël AVILA
2025-06-27 7:49 ` [GSoC][RFC PATCH 2/2] t: add test for git refs list subcommand Meet Soni
2025-06-27 18:03 ` [GSoC][RFC PATCH 0/2] Add " Junio C Hamano
2025-06-28 8:05 ` shejialuo
2025-06-30 14:05 ` Junio C Hamano
2025-07-06 12:58 ` shejialuo
2025-06-30 3:53 ` Meet Soni
2025-06-30 20:10 ` Junio C Hamano
2025-07-09 13:36 ` Patrick Steinhardt
2025-07-17 7:50 ` [GSoC][RFC PATCH v2 " Meet Soni
2025-07-17 7:50 ` [GSoC][RFC PATCH v2 1/2] builtin/refs: add " Meet Soni
2025-07-17 16:48 ` Eric Sunshine
2025-07-23 5:01 ` Meet Soni
2025-07-17 7:50 ` [GSoC][RFC PATCH v2 2/2] t: add test for git refs " Meet Soni
2025-07-17 21:01 ` Junio C Hamano
2025-07-23 5:17 ` Meet Soni
2025-07-23 15:03 ` Junio C Hamano
2025-07-23 6:43 ` [GSoC][RFC PATCH v3 0/3] Add " Meet Soni
2025-07-23 6:43 ` [GSoC][RFC PATCH v3 1/3] builtin/refs: add " Meet Soni
2025-07-24 5:58 ` Patrick Steinhardt
2025-07-24 16:01 ` Junio C Hamano
2025-07-25 11:10 ` Meet Soni
2025-07-23 6:43 ` [GSoC][RFC PATCH v3 2/3] t6300: refactor tests to be shareable Meet Soni
2025-07-23 6:43 ` [GSoC][RFC PATCH v3 3/3] t: add test for git refs list subcommand Meet Soni
2025-07-31 9:00 ` [GSoC][RFC PATCH v4 0/5] Add " Meet Soni
2025-07-31 9:00 ` [GSoC][RFC PATCH v4 1/5] doc: factor out common option Meet Soni
2025-07-31 9:00 ` [GSoC][RFC PATCH v4 2/5] builtin/for-each-ref: factor out core logic into a helper Meet Soni
2025-08-01 5:54 ` Patrick Steinhardt
2025-08-04 6:34 ` Meet Soni
2025-07-31 9:00 ` [GSoC][RFC PATCH v4 3/5] builtin/refs: add list subcommand Meet Soni
2025-08-01 13:27 ` Phillip Wood
2025-08-01 14:43 ` Junio C Hamano
2025-08-01 15:49 ` Phillip Wood
2025-08-01 17:14 ` Junio C Hamano
2025-08-04 9:28 ` Phillip Wood
2025-08-04 6:32 ` Meet Soni
2025-08-04 9:27 ` Phillip Wood
2025-08-04 15:35 ` Junio C Hamano [this message]
2025-07-31 9:00 ` [GSoC][RFC PATCH v4 4/5] t6300: refactor tests to be shareable Meet Soni
2025-07-31 9:00 ` [GSoC][RFC PATCH v4 5/5] t: add test for git refs list subcommand Meet Soni
2025-08-01 5:54 ` [GSoC][RFC PATCH v4 0/5] Add " Patrick Steinhardt
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 0/6] " Meet Soni
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 1/6] doc: factor out common option Meet Soni
2025-08-04 18:34 ` Junio C Hamano
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 2/6] builtin/for-each-ref: align usage string with the man page Meet Soni
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 3/6] builtin/for-each-ref: factor out core logic into a helper Meet Soni
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 4/6] builtin/refs: add list subcommand Meet Soni
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 5/6] t6300: refactor tests to be shareable Meet Soni
2025-08-04 9:22 ` [GSoC][RFC PATCH v5 6/6] t: add test for git refs list subcommand Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 0/6] Add " Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 1/6] doc: factor out common option Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 2/6] builtin/for-each-ref: align usage string with the man page Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 3/6] builtin/for-each-ref: factor out core logic into a helper Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 4/6] builtin/refs: add list subcommand Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 5/6] t6300: refactor tests to be shareable Meet Soni
2025-08-05 9:27 ` [GSoC][PATCH v6 6/6] t: add test for git refs list subcommand Meet Soni
2025-08-05 13:07 ` [GSoC][PATCH v6 0/6] Add " Patrick Steinhardt
2025-08-05 16:12 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqh5yn6qxg.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=johncai86@gmail.com \
--cc=karthik.188@gmail.com \
--cc=meetsoni3017@gmail.com \
--cc=phillip.wood123@gmail.com \
--cc=ps@pks.im \
--cc=shejialuo@gmail.com \
--cc=sunshine@sunshineco.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).