From: Phillip Wood Date: Mon, 05 Feb 2024 18:48:52 GMT Subject: Re: [PATCH v3 4/4] for-each-ref: avoid filtering on empty pattern Message-ID: <98d79d33-0d7e-4a9c-a6a3-ed9b58cd7445@gmail.com> In-Reply-To: <20240129113527.607022-5-karthik.188@gmail.com> Hi Karthik On 29/01/2024 11:35, Karthik Nayak wrote: > When the user uses an empty string pattern (""), we don't match any refs > in git-for-each-ref(1). This is because in git-for-each-ref(1), we use > path based matching and an empty string doesn't match any path. > > In this commit we change this behavior by making empty string pattern > match all references. This is done by introducing a new flag > `FILTER_REFS_NO_FILTER` in `ref-filter.c`, which uses the newly > introduced `refs_for_each_all_refs()` function to iterate over all the > refs in the repository. It actually iterates over all the refs in the current worktree, not all the refs in the repository. I have to say that I find it extremely unintuitive that "" behaves differently to not giving a pattern. I wonder if we can find a better UI here - perhaps a command line option to include pseudorefs? > Signed-off-by: Karthik Nayak > --- > Documentation/git-for-each-ref.txt | 3 ++- > builtin/for-each-ref.c | 21 +++++++++++++++++- > ref-filter.c | 13 ++++++++++-- > ref-filter.h | 4 +++- > t/t6302-for-each-ref-filter.sh | 34 ++++++++++++++++++++++++++++++ > 5 files changed, 70 insertions(+), 5 deletions(-) > > diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt > index be9543f684..b1cb482bf5 100644 > --- a/Documentation/git-for-each-ref.txt > +++ b/Documentation/git-for-each-ref.txt > @@ -32,7 +32,8 @@ OPTIONS > If one or more patterns are given, only refs are shown that > match against at least one pattern, either using fnmatch(3) or > literally, in the latter case matching completely or from the > - beginning up to a slash. > + beginning up to a slash. If an empty string is provided all refs > + are printed, including HEAD and pseudorefs. I think it would be helpful to clarify that it is all the refs for the current worktree that are printed, not all the refs in the repository - we still don't have a way to iterate over the per-worktree refs from other worktrees Best Wishes Phillip