Re: [PATCH 2/2] ref-filter: support filtering of operational refs

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 3, 2024, 14:38 UTC
Message-ID: <xmqqwmsqbhyt.fsf@gitster.g>
In-Reply-To: <CAOLa=ZS4OOAmyRvf4HH-c_3GvnVkh6zS2kD3hEhRZ7NZT-rvyA@mail.gmail.com>

Karthik Nayak <karthik.188@gmail.com> writes:

Show 6 quoted lines

> The confusion was that I thought Junio was referring to using
>
>     $ git for-each-ref ""
>
> to print all refs under $GIT_DIR, while he was actually talking about
> "$GIT_DIR/refs/" directory.

I do not think you misunderstood me here, though.

When you have your master branch (refs/heads/master), your v1.0 tag (refs/tags/v1.0), and the usual pseudorefs, giving "refs" to "git for-each-ref" would yield refs/heads/master and refs/tags/v1.0 but not HEAD and others, simply because the pattern "refs" in

    $ git for-each-ref "refs"

works as a hierarchy prefix match. You give "refs/heads" and you get only your master branch but not tags or HEAD in such a repository. As a natural extension to that behaviour, an empty string as a hierarchy prefix that matches everything would work well: you'd get HEAD, refs/heads/master, and refs/tags/v1.0 as an empty prefix would cover all of the hiearchies these three refs (and pseudorefs if you had ORIG_HEAD and MERGE_HEAD there) live in.

In any case, it is not a very much interesting to define the syntax to tell for-each-ref not to limit itself under "refs/". My point was that you do not need a special option for that, as shown above.

What is more interesting is what to do with refs that are specific to other worktrees, e.g.

    $ git rev-parse "worktrees/$name/refs/bisect/bad"

would currently let you peek into (and worse yet, muck with, if you really wanted to, with something like "git update-ref") refs that should be only visible in another worktree. Should for-each-ref and friends learn a way to iterate over them? I have no answer to that question.