Karthik Nayak <karthik.188@xxxxxxxxx> writes:
> 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.
