All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.